Re: z/VM 6.1, SSLSERV Question
Date: Wed, 1 Dec 2010 17:10:41 -0500 From: alan_altm...@us.ibm.com Subject: Re: z/VM 6.1, SSLSERV Question To: IBMVM@LISTSERV.UARK.EDU snip Btw, I don't see very much pressure being placed on z/VM to provide client-side TLS support for homegrown RxSocket or Pipeline apps. I see slightly more pressure for VM to provide user certificate-based single- and two-factor authentication for TN3270E (and, inevitably, ftp and smtp). Alan Altmark It would be nice if UFT(D) would support it. Mark Wheeler UnitedHealth Group
Re: z/VM 6.1, SSLSERV Question
On Thursday, 12/02/2010 at 08:15 EST, Mark Wheeler mwheele...@hotmail.com wrote: It would be nice if UFT(D) would support it. RFC 1440 does not define a mechanism for the UFT client and server to negotiate and initiate TLS. A new RFC is needed. (Note that the IETF now requires protocols to be able to negotiate TLS on the same port as the unsecured version.) Further, UFT(D) in VM is not written to the VMCF/Pascal interface and so couldn't support it until CMS supports dynamic TLS for IUCV sockets. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 alan_altm...@us.ibm.com IBM Endicott
Re: z/VM 6.1, SSLSERV Question
RXSSL comes to mind. As it happens, a couple of us were discussing RXSSL off-list within the past day. Seems that it may need some attention to get it working with the new VM SSL. -- R; Rick Troth Velocity Software http://www.velocitysoftware.com/ On Wed, Dec 1, 2010 at 11:43, Schuh, Richard rsc...@visa.com wrote: Thanks for the reply, Alan. So it is not possible using RXSOCKET. Is it possible from a CMS client running a home-grown assembler or Pipelines program, or is it a lost cause? Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark Sent: Wednesday, December 01, 2010 6:53 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: z/VM 6.1, SSLSERV Question On Tuesday, 11/30/2010 at 06:39 EST, Schuh, Richard rsc...@visa.com wrote: We have a person who is trying to get a secure end-to-end transaction between a CMS client and a TPF host. RXSOCKET is being used by the CMS client. The port specified is 51105, which has been designated as a secure port. He has traced the SSLSERV and sees no traffic going through it; however, the connection to TPF is made and it is not secure. The ASSORTEDPARMS are coded as: ASSORTEDPARMS SECURELOCAL PROXYARP IGNOREREDIRECT FREELOWPORTS ENDASSORTEDPARMS What is the magic that will allow this to be done. None. The description of SecureLocal is somewhat deficient. It applies only to loopback connections and only to sockets managed by the Pascal/VMCF socket interface. The RxSocket/C/IUCV socket interface does not have support for SSL. Under normal circumstances, loopback connections for static SSL connections would be superfluous since the traffic never leaves the stack and the secured apps can't tell the difference. SecureLocal overrides that decision in case you have a stack that you want to use for testing the management and use of SSL. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 alan_altm...@us.ibm.com IBM Endicott
Re: z/VM 6.1, SSLSERV Question
Yep. A new RFC is needed. The original author has been saying that for ten years, has asked for collaborators, and is still open. The original design intentionally left compression and encryption out of scope. The advent of SSL suggests that was probably a good choice. ZIP has been around since long before UFT. GZIP was there at the start. Both of these have some functionality on CMS, but not well integrated. But we were talking about SSL, not compression. Sorry. Negotiation was worked on, but has never made it into a follow-on RFC. (Probably because there is no follow-on RFC ... yet.) Authentication in UFT suggests how TLS/SSL negotiation might be done because authentication was always open and variable ... negotiated. The bottom line for UFT is to do over TCP what RSCS does over CTC/VTAM/NJE, but not in the way NJE/IP does. (Of course, it might be a good hint to the present NJE/IP authors and owners to create a UFT driver for their stuff. hint hint) The point is that UFT gives you RSCS-style transport without adding more network topology. If then you are behind a firewall, you might not care to secure the UFT channels. (Did he just say that? He did! I can't believe he said that!) -- R; On Thu, Dec 2, 2010 at 08:29, Alan Altmark alan_altm...@us.ibm.com wrote: On Thursday, 12/02/2010 at 08:15 EST, Mark Wheeler mwheele...@hotmail.com wrote: It would be nice if UFT(D) would support it. RFC 1440 does not define a mechanism for the UFT client and server to negotiate and initiate TLS. A new RFC is needed. (Note that the IETF now requires protocols to be able to negotiate TLS on the same port as the unsecured version.) Further, UFT(D) in VM is not written to the VMCF/Pascal interface and so couldn't support it until CMS supports dynamic TLS for IUCV sockets. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 alan_altm...@us.ibm.com IBM Endicott
Re: z/VM 6.1, SSLSERV Question
On Thursday, 12/02/2010 at 09:32 EST, Richard Troth vmcow...@gmail.com wrote: RXSSL comes to mind. As it happens, a couple of us were discussing RXSSL off-list within the past day. Seems that it may need some attention to get it working with the new VM SSL. As I'm sure you have discovered, the challenges with SSL are many: - Certificate updates without taking applications out of service - Allowing different applications to use the same certificate - Protecting a server certificate's private key - Tying user certificates to VM user IDs so that people can be identified and two-factor authentication enabled - Keeping user certificate private keys away from the users (think about it) - Implementation of a flexible policy for the validation of incoming certificates - Keeping up with advancements in the protocol and the introduction of new encryption suites - Required industry and government certifications such as FIPS I would have thought that everyone's IT host network security departments would be turning the screws on unencrypted and unauthenticated transmission to/from VM of any sensitive data and/or passwords. (You mean you let MAINT's password flow in clear-text over the company's network?!?) And that you all, in turn, would be squeezing IBM for a supported, manageable solution. It's kind of scary, actually. My biggest fear is that folks are trying to fly under the radar in the hopes of not being discovered and are taking too many undocumented or ill-understood risks. But perhaps I am too paranoid. Maybe these all just trivial transmissions of today's cafeteria lunch menu and cannot be used by some disgruntled or creative employee to discredit, steal, corrupt, or destroy your fave virtualization platform or the data it holds. There are large corporations who are finally starting to look at z/VM management policies (incl. security) to ensure that they are mitigating the risks inherent in any virtualization strategy. It's easy to say, We'll deal with that later. Tick, tock, tick, tock. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 alan_altm...@us.ibm.com IBM Endicott
Re: z/VM 6.1, SSLSERV Question
Alan Altmark alan_altm...@us.ibm.com wrote :- I would have thought that everyone's IT host network security departments would be turning the screws on unencrypted and unauthenticated transmission to/from VM of any sensitive data and/or passwords. (You mean you let MAINT's password flow in clear-text over the company's network?!?) And that you all, in turn, would be squeezing IBM for a supported, manageable solution. It's kind of scary, actually. My biggest fear is that folks are trying to fly under the radar in the hopes of not being discovered and are taking too many undocumented or ill-understood risks. But perhaps I am too paranoid. Maybe these all just trivial transmissions of today's cafeteria lunch menu and cannot be used by some disgruntled or creative employee to discredit, steal, corrupt, or destroy your fave virtualization platform or the data it holds. There are large corporations who are finally starting to look at z/VM management policies (incl. security) to ensure that they are mitigating the risks inherent in any virtualization strategy. It's easy to say, We'll deal with that later. Tick, tock, tick, tock. Because of the very power of mainframe systems, the power of any Systems Programmer worth their salt makes them far too dangerous to have on-site - unless you really trust them. You can put all sorts of controls in place and make their job more difficult but, unless you take away all access that they need for their job, they can always get round any controls. That is not to say that there should be no controls at all - the main ones should be to prevent accidental or negligent issues. To make it easier to do it right than wrong. A lot of people are flying just under the Radar - not with mal intent, but to achieve what needs to be done. However, my company (along with many others) does have a strategy for dealing with this problem. Get rid of mainframe systems because we all KNOW that distributed systems handle these problems SO much better !!! In 4-5 years the risk will have been eliminated (along with all of us). Colin Allinson
Re: z/VM 6.1, SSLSERV Question
On Thursday, 12/02/2010 at 10:08 EST, Richard Troth vmcow...@gmail.com wrote: The bottom line for UFT is to do over TCP what RSCS does over CTC/VTAM/NJE, but not in the way NJE/IP does. (Of course, it might be a good hint to the present NJE/IP authors and owners to create a UFT driver for their stuff. hint hint) The point is that UFT gives you RSCS-style transport without adding more network topology. If then you are behind a firewall, you might not care to secure the UFT channels. (Did he just say that? He did! I can't believe he said that!) Bah, humbug. You simply added a new network with the label UFT instead of NJE. The problem with behind the firewall is that the firewall can appear to move since FW management isn't within your job description. Further, encryption is there to protect the data from sniffers (legitimate or otherwise). When the $10/hr network tech is diagnosing a problem, do you want him to have access to your 401K information while she's doing it? Hence the reason a data security policies may say, All PII shall be encrypted when at rest or transmitted on a network. No qualifiers and no escape clauses. You have to file for any exception. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 alan_altm...@us.ibm.com IBM Endicott
Re: z/VM 6.1, SSLSERV Question
No. Look again. There is an important topological difference between UFT and NJE-IP. UFT is just another IP protocol (one that looks more like RSCS than, say, FTP). Your network topology does not change. While NJE-over-IP is a network-on-a-network. Full-blown RSCS, but with a whole raft of nodes to define. Topology. Not saying either is better than the other. Both have value and cost. Both bring the wonderful concepts of job submission and a file is not an attachment to a world that did not have them. We should fork this thread. Or stop it. -- R; Rick Troth Velocity Software http://www.velocitysoftware.com/ On Thu, Dec 2, 2010 at 10:26, Alan Altmark alan_altm...@us.ibm.com wrote: On Thursday, 12/02/2010 at 10:08 EST, Richard Troth vmcow...@gmail.com wrote: The bottom line for UFT is to do over TCP what RSCS does over CTC/VTAM/NJE, but not in the way NJE/IP does. (Of course, it might be a good hint to the present NJE/IP authors and owners to create a UFT driver for their stuff. hint hint) The point is that UFT gives you RSCS-style transport without adding more network topology. If then you are behind a firewall, you might not care to secure the UFT channels. (Did he just say that? He did! I can't believe he said that!) Bah, humbug. You simply added a new network with the label UFT instead of NJE. The problem with behind the firewall is that the firewall can appear to move since FW management isn't within your job description. Further, encryption is there to protect the data from sniffers (legitimate or otherwise). When the $10/hr network tech is diagnosing a problem, do you want him to have access to your 401K information while she's doing it? Hence the reason a data security policies may say, All PII shall be encrypted when at rest or transmitted on a network. No qualifiers and no escape clauses. You have to file for any exception. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 alan_altm...@us.ibm.com IBM Endicott
Re: z/VM 6.1, SSLSERV Question
Does anyone have a sample SSL/TLS client assembler program that uses the VMCF interface? And would you be willing to share it/ If so, it isn't a lost cause. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark Sent: Wednesday, December 01, 2010 2:11 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: z/VM 6.1, SSLSERV Question On Wednesday, 12/01/2010 at 11:43 EST, Schuh, Richard rsc...@visa.com wrote: Thanks for the reply, Alan. So it is not possible using RXSOCKET. Is it possible from a CMS client running a home-grown assembler or Pipelines program, or is it a lost cause? A lost cause, I would say. Implicit/Static TLS/SSL is available for any TCP/IP *server* without regard to the interface being used. I.e. an IUCV, C, RxSocket or Pipeline server can be protected by the SECURE parameter on the PORT statement. However, there is no such support for clients. If a connection to a SECURE port (static) comes from an app on the same stack AND the SecureLocal parm is specified, the stack will treat it as it would an inbound external connection and route the connection through the SSL server on behalf of the *server* side only. For clients, only dynamic/negotiated TLS/SSL support is available, and that is only via the VMCF/Pascal API. Btw, I don't see very much pressure being placed on z/VM to provide client-side TLS support for homegrown RxSocket or Pipeline apps. I see slightly more pressure for VM to provide user certificate-based single- and two-factor authentication for TN3270E (and, inevitably, ftp and smtp). Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 alan_altm...@us.ibm.com IBM Endicott
Re: z/VM 6.1, SSLSERV Question
What command are you issuing on the CMS client? Alan Ackerman
Re: z/VM 6.1, SSLSERV Question
On Tuesday, 11/30/2010 at 06:39 EST, Schuh, Richard rsc...@visa.com wrote: We have a person who is trying to get a secure end-to-end transaction between a CMS client and a TPF host. RXSOCKET is being used by the CMS client. The port specified is 51105, which has been designated as a secure port. He has traced the SSLSERV and sees no traffic going through it; however, the connection to TPF is made and it is not secure. The ASSORTEDPARMS are coded as: ASSORTEDPARMS SECURELOCAL PROXYARP IGNOREREDIRECT FREELOWPORTS ENDASSORTEDPARMS What is the magic that will allow this to be done. None. The description of SecureLocal is somewhat deficient. It applies only to loopback connections and only to sockets managed by the Pascal/VMCF socket interface. The RxSocket/C/IUCV socket interface does not have support for SSL. Under normal circumstances, loopback connections for static SSL connections would be superfluous since the traffic never leaves the stack and the secured apps can't tell the difference. SecureLocal overrides that decision in case you have a stack that you want to use for testing the management and use of SSL. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 alan_altm...@us.ibm.com IBM Endicott
Re: z/VM 6.1, SSLSERV Question
Thanks for the reply, Alan. So it is not possible using RXSOCKET. Is it possible from a CMS client running a home-grown assembler or Pipelines program, or is it a lost cause? Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark Sent: Wednesday, December 01, 2010 6:53 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: z/VM 6.1, SSLSERV Question On Tuesday, 11/30/2010 at 06:39 EST, Schuh, Richard rsc...@visa.com wrote: We have a person who is trying to get a secure end-to-end transaction between a CMS client and a TPF host. RXSOCKET is being used by the CMS client. The port specified is 51105, which has been designated as a secure port. He has traced the SSLSERV and sees no traffic going through it; however, the connection to TPF is made and it is not secure. The ASSORTEDPARMS are coded as: ASSORTEDPARMS SECURELOCAL PROXYARP IGNOREREDIRECT FREELOWPORTS ENDASSORTEDPARMS What is the magic that will allow this to be done. None. The description of SecureLocal is somewhat deficient. It applies only to loopback connections and only to sockets managed by the Pascal/VMCF socket interface. The RxSocket/C/IUCV socket interface does not have support for SSL. Under normal circumstances, loopback connections for static SSL connections would be superfluous since the traffic never leaves the stack and the secured apps can't tell the difference. SecureLocal overrides that decision in case you have a stack that you want to use for testing the management and use of SSL. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 alan_altm...@us.ibm.com IBM Endicott
Re: z/VM 6.1, SSLSERV Question
On Wednesday, 12/01/2010 at 11:43 EST, Schuh, Richard rsc...@visa.com wrote: Thanks for the reply, Alan. So it is not possible using RXSOCKET. Is it possible from a CMS client running a home-grown assembler or Pipelines program, or is it a lost cause? A lost cause, I would say. Implicit/Static TLS/SSL is available for any TCP/IP *server* without regard to the interface being used. I.e. an IUCV, C, RxSocket or Pipeline server can be protected by the SECURE parameter on the PORT statement. However, there is no such support for clients. If a connection to a SECURE port (static) comes from an app on the same stack AND the SecureLocal parm is specified, the stack will treat it as it would an inbound external connection and route the connection through the SSL server on behalf of the *server* side only. For clients, only dynamic/negotiated TLS/SSL support is available, and that is only via the VMCF/Pascal API. Btw, I don't see very much pressure being placed on z/VM to provide client-side TLS support for homegrown RxSocket or Pipeline apps. I see slightly more pressure for VM to provide user certificate-based single- and two-factor authentication for TN3270E (and, inevitably, ftp and smtp). Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 alan_altm...@us.ibm.com IBM Endicott
