Overview of ZEN EE SECURITY - APIAS: Enterprise Extender Security and Connectivity
for z/OS Mainframes.
ZEN EE SECURITY - APIAS comprises three primary functions:
SSL transport for Enterprise Extender (SSL Enterprise Extender)
Enables you to SSL secure all traffic passing across an Enterprise Extender link
between systems. It works by converting the Enterprise Extender UDP packets to TCP
packets and then SSL encrypting them prior to transmission. On receipt, ZEN EE SECURITY
- APIAS decrypts the packets, and reconverts them to UDP packets which are then
passed to the standard Enterprise Extender ports.
TCP transport for Enterprise Extender (TCP Enterprise Extender)
This function is provided for companies that do not permit UDP traffic on their
networks which would therefore exclude the use of Enterprise Extender. In this mode,
ZEN EE SECURITY - APIAS converts the Enterprise Extender UDP packets to TCP packets
and it is these that flow across the Enterprise Extender link. Although SSL encryption
is not done in this mode (the assumption being that either it is not required, or
that it is being done at the VTAM level), ZEN EE SECURITY - APIAS is able to use
digital certificates for authentication.
Multiple stack support for Enterprise Extender
This feature enables Enterprise Extender to work with multiple stacks in the same
LPAR, a capability not normally allowed. As with the TCP transport feature, ZEN
EE SECURITY - APIAS can optionally use digital certificates for authentication although
this would require ZEN EE SECURITY - APIAS to be running at both ends of the Enterprise
Extender link and therefore currently limits this authentication to z/OS only. If
authentication is not required, the target Enterprise Extender system can be non-z/OS,
for example an IBM 2216, PCOM, CISCO routers, CS for LINUX and so on. For z/OS systems,
this facility can be combined with either the TCP or SSL features. ZEN EE SECURITY
- APIAS is simple and quick to install and configuration is through a standard PARMLIB
member that can be edited using the standard ISPF editor.
SSL Transport for Enterprise Extender
Enterprise Extender enables SNA (HPR) traffic to be transmitted over an IP network.
SNA data is carried in UDP packets on registered UDP ports 12000 to 12004. Port
12000 is used for XID and NLP exchanges, and ports 12001 to 12004 are mapped to
the APPN transmission priorities.
Since Enterprise Extender relies on encapsulating SNA data in UDP packets which
are not normally encrypted or authenticated, Enterprise Extender is usually not
an acceptable method of transmitting sensitive corporate data between sites, especially
where part of the network is known to be inherently insecure. With the imminent
demise of IBM’s 3745 communications controller, many companies are being forced
to consider what alternative secure network options they have.
ZEN EE SECURITY - APIAS provides the means of using IBM’s Enterprise Extender unchanged
in a secure way, irrespective of the network routes used, including the Internet,
between the source and target IP addresses.
It works by converting the Enterprise Extender UDP packets to TCP packets and then
SSL encrypting them prior to transmission. On receipt, ZEN EE SECURITY - APIAS decrypts
the packets, and reconverts them to UDP packets which are then passed to the standard
Enterprise Extender ports. Prior to any transmission taking place, full digital
certificate authentication can take place between the source and target systems
so you are assured that the link is fully secure.
Neither the source nor the target system is aware of any of this conversion process
happening. The target system simply sees the UDP packets on the standard ports 12000
to 12004 as if they had been received directly from the source system. Thus, ZEN
EE SECURITY - APIAS provides full authentication and encryption security in a situation
in which it would not normally be available, and without the disruption caused by
major system changes.
TCP Transport for Enterprise Extender
For reasons of security, many Installations do not permit UDP traffic to be carried
on their IP networks which can present a migration problem given the discontinuation
of the 3745 SNA controller. However, ZEN EE SECURITY - APIAS can convert the Enterprise
Extender UDP packets to TCP packets and transmit them across the network. At the
remote end of the connection, ZEN EE SECURITY - APIAS converts the packets back
to UDP and passes them to the Enterprise Extender ports. As far as the system is
concerned, no change has taken place since it is still receiving UDP packets on
the standard Enterprise Extender ports, however, the UDP protocol restriction has
For additional security ZEN EE SECURITY - APIAS can optionally authenticate the
connection between the source and target systems using a digital certificate. Note,
however, that in this mode of operation, ZEN EE SECURITY - APIAS is not encrypting
the TCP packets that are sent across the network (although it can of course do this
if required as described in the previous section).
Multiple Stack Support for Enterprise Extender
In a situation where an Installation, often for reasons of security, is running
multiple stacks in a LPAR, Enterprise Extender is only allowed to be used on one
of them. This restriction can cause difficulties if each stack is required to route
traffic to different remote sites and Enterprise Extender is required for enabling
SNA traffic to be carried by the IP network. Generally, this would require radical
system changes to split the stacks across separate LPARs with all of the system
redefinition and disruption this would cause.
ZEN EE SECURITY - APIAS can resolve this difficulty by enabling Enterprise Extender
traffic to be routed through any of the stacks on the LPAR without any major changes
to the current LPAR definitions. By running ZEN EE SECURITY - APIAS on each stack,
it can pick up the Enterprise Extender packets and route them as required to the
‘other’ IP stacks or systems. At the simplest level, ZEN EE SECURITY - APIAS simply
performs UDP packet relaying between the IP stacks but you could combine this capability
with the TCP Transport function which would enable you to authenticate the connection
between the source and target systems using a digital certificate. If this is not
a requirement, a ‘target’ Enterprise Extender system could be non-z/OS such as PCOM,
or a variety of CISCO routers.
Frequently Asked Questions
Does ZEN EE SECURITY - APIAS support the X509 Certificate standard and if so is
The answer to this is yes. ZEN EE SECURITY - APIAS encryption and authentication
is provided by an API to System SSL (part of z/OS). They key question is ‘Does System
SSL support X509 and PKI and the answer again, is yes.
The following text can be found in: Communications Server for z/OS V1R2 TCP/IP
Implementation Guide Volume 7: Security - SG24 6840: In z/OS System SSL provides
a common set of libraries and an API. System SSL is part of the System SSL Cryptographic
Services Base element of z/OS. z/OS Communications Server uses the System SSL APIs
to create and manage SSL connections. X.509 certificates are used by both the client
and server when securing communications using System SSL
System SSL supports the following two methods for managing PKI private keys and
- A z/OS shell-based program called gskkyman. gskkyman creates, fills in, and manages
a z/OS HFS file that contains PKI private keys, certificate requests, and certificates.
This z/OS HFS file is called a key database and, by convention, has a file extension
- The z/OS SecureWay Security Server (RACF) RACDCERT command. RACDCERT installs
and maintains PKI private keys and certificates in RACF. RACF supports multiple
PKI private keys and certificates to be managed as a group. These groups are called
keyrings. RACF keyrings are the preferred method for managing PKI private keys and
certificates for System SSL.”
ZEN EE SECURITY - APIAS implementation of authentication supports both gskkyman
and RACF keyrings.
Can ZEN EE SECURITY - APIAS be used to secure applications other than Enterprise
William Data Systems has chosen to focus on Enterprise Extender security because
IBM already offers alternative facilities for encrypting and authenticating TCP/IP
With z/OS 1.7 IBM introduced a new Application Transparent Transport Layer Security
(AT-TLS) function in the TCP/IP stack to provide TLS for TCP/IP sockets applications
that require secure connections. AT-TLS performs TLS on behalf of the application
by invoking the z/OS System Secure Socket Layer (SSL) in the TCP transport layer
of the stack. System SSL provides support for TLSv1, SSLv3, and SSLv2 protocols.
Further information about AT-TLS can be found in IBM Redbook SG24-7172: Communications
Server for z/OS V1R7 TCP/IP Implementation, Volume 4 Policy-Based Network Security.
Is it necessary to have a copy of ZEN EE SECURITY - APIAS at each end of the connection?
The answer to this is yes. ZEN EE SECURITY - APIAS removes the SNA data from
the UDP packets and places it in TCP packets. Once it is TCP-encapsulated ZEN EE
SECURITY - APIAS applies SSL authentication and encryption to the TCP packets (SSL
does not support UDP). A copy of ZEN EE SECURITY - APIAS is required at the other
end of the Enterprise Extender connection to decrypt the packets and place the data
back into UDP packets.
Does ZEN EE SECURITY - APIAS support SYSPLEX Distributor or Dynamic VIPA?
ZEN EE SECURITY - APIAS works with Dynamic VIPAs and there is nothing in the ZEN
EE SECURITY - APIAS code to prevent it working in a Sysplex Distributor environment.
Sysplex Distributor enables applications to be distributed across different LPARs
with some element of dynamic re-routing. ZEN EE SECURITY - APIAS is not an application,
it is a network service. Multiple ZEN EE SECURITY - APIAS instances can be active
within a Sysplex Distributor environment but since ZEN EE SECURITY - APIAS only
supports point-to-point secure connections (as does Enterprise Extender) to partner
Enterprise Extender systems, it is not clear how customers would want to use Sysplex
Distributor and ZEN EE SECURITY - APIAS/EE.
Does ZEN EE SECURITY - APIAS support the SRCIP function?
Source IP addressing enables an application to always have the same source IP address
when transmitting packets to the outside world. However, this only applies to applications
which BIND to a null IP address. Both Enterprise Extender and ZEN EE SECURITY -
APIAS bind to a specific IP address, so outbound packets will (and must) contain
Does ZEN EE SECURITY - APIAS have a facility to establish connections (tunnels)
on demand, as some firewall systems do?
The major difference between ZEN EE SECURITY - APIAS and an IPSec-based solution
is that ZEN EE SECURITY - APIAS is operating at the application layer and IPSec
is a function of the connection layer. However, ZEN EE SECURITY - APIAS to ZEN EE
SECURITY - APIAS connections through SSL could be viewed as a tunnel. They
are predefined in the ZEN EE SECURITY - APIAS configuration and can be dynamically
activated and de-activated by command.
Some level of automation could be achieved using standard Automatic Operations software.
ZEN EE SECURITY - APIAS will not dynamically allocate tunnels based on traffic
flow as the tunnel needs to be open before traffic can flow and dynamically allocating
tunnels based on traffic rather than configuration would be a security exposure.