Channels ▼
RSS

Design

Secure Data Exchange with Mainframes Under z/OS


Secure Data Exchange

Even if the "FTP only" rumors persist the mainframe can be accessed by modern secure protocols. Today you can transfer files to/from z/OS by several encrypted protocols which can be separated in three families:

  • TN3270 over SSL/TLS with IND$FILE
  • FTP over SSL/TLS (FTPS)
  • SSH-based techniques such as SSH FTP (SFTP) and SSH Copy (SCP)

TN3270 is a TCP/IP service which bases upon TELNET and brings us the 3270 screen onto our desktop. It can be secured by SSL/TLS as well. By a program called IND$FILE it is possible to transfer files from PC to the mainframe and vice versa in a 3270 emulator session. If TN3270 runs over SSL/TLS these file transfers are encrypted, too. IND$FILE is useful to user's file transfers in interactive TSO sessions but inadequate for automated file transfers to/from the host. It is mentioned here only for the record.

The appropriate solutions for exchanging files with z/OS is FTPS and SFTP/SCP. Other unencrypted transfer methods such as FTP or in USS rcp, should be banned on the mainframe as they were banned on other system, namely Unix and OpenVMS. Even if these protocols have a long tradition, they are insecure. There is no more excuse to use them today.

SSL/TLS Certificates and RACF

z/OS supports SSL and TLS. The necessary certificates can be stored either in RACF under MVS or in files under UNIX System Services (USS). RACF is the typical way on z/OS to store authentication data. It can be administered by TSO commands or a bit more user friendly by ISPF panels (with some restrictions). USS puts the certificates upon a UNIX filesystem (HFS or ZFS) into files called keystores. People familiar with WebSphere AS or IBM HTTPD Server know this method already. The tool ikeyman is exactly what is used here. Those of us who know only "generic" Java may have crossed the way of Sun's keytool which does indeed the same.

To enable SSL/TLS in the FTP server of z/OS it makes more sense to store the certificates in RACF. This is for one simple reason: The FTP server is a MVS address space (= process) and will be spawned at IPL (Initial Program Load = boot) of the mainframe independently from USS. Even if the FTP server integrates fully into USS, it makes no sense to create a dependency to USS here. If USS, or ZFS, fails to start for some reason, FTPS won't be available because the FTP server won't find its keystore. If your certificates reside in RACF and RACF doesn't start you will encounter much more serious problems at other corners of your system. In this situation your complaining FTP server will be the least of your problems. So put your certificates into RACF. Furthermore RACF is the main resource for authentication on the mainframe. So if you can use it!

For management of certificates within RACF exist an ISPF panel and the TSO command RACDCERT. With the help of ISPF panel you can easily and intuitive manage SSL/TLS certificates (see Figure 1). RACDCERT also offers the necessary operations to create, export and import personal and CA (certificate authority) certificates. RACF organizes certificates in keyrings. These keyrings fulfill the same purpose like keystores in Java and open systems. They contain the personal certificates which are used directly for encryption as well as the signing CA certificates.

[Click image to view at full size]
Figure 1

With RACF profiles you can (and have to) restrict the access to the key rings and certificates. Listing 1 shows a CLIST script which generates a minimal frame for certificate management. First it restricts the access to certificates per default to nobody (commands RDEFINE with parameter UACC(NONE)). Second (PE = PERMIT commands) it permits again whole access for a group of certificate administrators. To all other users it allows to read and use certificates and to manage their keyrings. The admin group is given at execution as a parameter (ADMGRP). To execute this CLIST you have to invoke it from TSO as:


EXEC 'HLQ.CERTPERM.CLIST' 'GCERT' CLIST

HLQ is the high-level qualifier of the data set. GCERT is an example of a group in which the administrators reside. You have to adjust these parameters for your system of course. (Note: On real-world installations more fine-tuned access rights might be needed!


/* CERTPERM.CLIST                                    */
/* SET PERMISSIONS FOR CERTIFICATE MANAGEMENT        */
/* PARAMETERS:                                       */
/* ADMGRP = RACF GROUP OF CERTIFICATE ADMINISTRATORS */
PROC 1 ADMGRP
SUBMIT * END($$)
//CERTPERM JOB (),'CERTPERM',CLASS=A,
//  MSGCLASS=X,MSGLEVEL=(1,1),NOTIFY=&SYSUID
//GENPROF EXEC PGM=IKJEFT01
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD *
SETR CLASSACT(DIGTCERT DIGTCRIT DIGTNMAP DIGTRING)
SETR RACLIST(DIGTCERT DIGTCRIT DIGTNMAP DIGTRING)
SETROPTS GENERIC(FACILITY)
RDEFINE FACILITY IRR.DIGTCERT.**        UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.ADD       UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.ADDRING   UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.ALTER     UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.ALTMAP    UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.CHECKCERT UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.CONNECT   UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.DELETE    UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.DELMAP    UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.DELRING   UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.EXPORT    UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.EXPORTKEY UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.GENCERT   UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.GENREQ    UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.LIST      UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.LISTMAP   UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.LISTRING  UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.MAP       UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.REMOVE    UACC(NONE)
SETROPTS RACLIST(FACILITY) REFRESH
SETROPTS GENERIC(FACILITY) REFRESH
PE IRR.DIGTCERT.**        CL(FACILITY) ID(&ADMGRP) ACC(CONTROL)
PE IRR.DIGTCERT.ADD       CL(FACILITY) ID(&ADMGRP) ACC(CONTROL)
PE IRR.DIGTCERT.ADDRING   CL(FACILITY) ID(&ADMGRP) ACC(CONTROL)
PE IRR.DIGTCERT.ALTER     CL(FACILITY) ID(&ADMGRP) ACC(CONTROL)
PE IRR.DIGTCERT.ALTMAP    CL(FACILITY) ID(&ADMGRP) ACC(CONTROL)
PE IRR.DIGTCERT.CHECKCERT CL(FACILITY) ID(&ADMGRP) ACC(CONTROL)
PE IRR.DIGTCERT.CONNECT   CL(FACILITY) ID(&ADMGRP) ACC(CONTROL)
PE IRR.DIGTCERT.DELETE    CL(FACILITY) ID(&ADMGRP) ACC(CONTROL)
PE IRR.DIGTCERT.DELMAP    CL(FACILITY) ID(&ADMGRP) ACC(CONTROL)
PE IRR.DIGTCERT.DELRING   CL(FACILITY) ID(&ADMGRP) ACC(CONTROL)
PE IRR.DIGTCERT.EXPORT    CL(FACILITY) ID(&ADMGRP) ACC(CONTROL)
PE IRR.DIGTCERT.EXPORTKEY CL(FACILITY) ID(&ADMGRP) ACC(CONTROL)
PE IRR.DIGTCERT.GENCERT   CL(FACILITY) ID(&ADMGRP) ACC(CONTROL)
PE IRR.DIGTCERT.GENREQ    CL(FACILITY) ID(&ADMGRP) ACC(CONTROL)
PE IRR.DIGTCERT.LIST      CL(FACILITY) ID(&ADMGRP) ACC(CONTROL)
PE IRR.DIGTCERT.LISTMAP   CL(FACILITY) ID(&ADMGRP) ACC(CONTROL)
PE IRR.DIGTCERT.LISTRING  CL(FACILITY) ID(&ADMGRP) ACC(CONTROL)
PE IRR.DIGTCERT.MAP       CL(FACILITY) ID(&ADMGRP) ACC(CONTROL)
PE IRR.DIGTCERT.REMOVE    CL(FACILITY) ID(&ADMGRP) ACC(CONTROL)
PE IRR.DIGTCERT.LIST      CL(FACILITY) ID(*)       ACC(READ)
PE IRR.DIGTCERT.LISTRING  CL(FACILITY) ID(*)       ACC(CONTROL)
SETROPTS RACLIST(DIGTCERT) REFRESH
$$

Now where the frame exists certificates can be created or imported. RACF identifies certificates by labels. A common source on the case-insensitive z/OS is that these labels are case-sensitive and allowed to contain spaces. So it is necessary to quote them in TSO and to have an eye on what you type. At LABEL or WITHLABEL parameters you should be carefully and always use '...' to quote.

You have to import CA certificate of your organization into RACF before continuing with the next steps. This can be done by the corresponding ISPF panel of RACF or by the TSO command RACDCERT IMPORT. For more information about RACDCERT IMPORT see HELP RDIMPORT at TSO prompt.

The following RACDCERT GENCERT command creates a new certificate. It signs it with the CA certificate labeled as "MAIN CA". We assume here that the FTP server will run under user ID "FTPD". Therefore the certificate is created for this user (see parameter ID). RACDCERT takes the parameters for the certificate such as host name, organization, country etc. as arguments:


RACDCERT ID(FTPD) GENCERT SUBJECTSDN(CN('zos.somewhere.com') +
O('SOMEWHERE') C('US')) WITHLABEL('FTPS Certificate') +
SIGNWITH(CERTAUTH LABEL('MAIN CA'))

Our FTP server needs this certificate in a key ring so that it can use it. RACDCERT ADDRING creates a new key ring for user FTPD which we will call FTPSKR. You have to take care for names of keyrings, too. They are also case-sensitive but not allowed to contain spaces.


RACDCERT ID(FTPD) ADDRING(FTPSKR)

Now we need to add to this key ring the signing certificate and the personal certificate which we created before. For this purpose the TSO command RACDCERT CONNECT exists. Two calls add the necessary certificates identified by their labels. The personal certificate "FTPS Certificate" will be the default for en-/decryption in keyring FTPSKR:


RACDCERT ID(FTPD) CONNECT(CERTAUTH LABEL('MAIN CA') RING(FTPSKR))
RACDCERT ID(FTPD) CONNECT(LABEL('FTPS Certificate') RING(FTPSKR) DEFAULT)

FTP over SSL/TLS

FTPS is separated into two versions: Explicit and implicit FTPS. At explicit FTPS, the initial connect is unencrypted. The client has to request SSL or TLS explicitly by issuing as the very first FTP command AUTH SSL or AUTH TLS to the server. If implicit FTPS is used the connection is encrypted from the beginning.

Explicit FTPS (FTPES) is defined in RFC 4217 since 2005. So it follows a clear standard. FTPES is supported by z/OS fully compliant to RFC 4217. Implicit FTPS in contrast is not clearly standardized. Because of this lack of standardization many incompatible implicit FTPS implementations appeared. Over the last years most FTP vendors committed by implementation to a quasi standard to avoid problems of incompatibility. Unfortunately z/OS was here -- as so often -- a bit special. Only since version 1.10, which was released in fall of 2008, z/OS was able to support this quasi standard. Until 1.9 it supported only its own implementation of implicit FTPS. This implementation could only interconnect z/OS systems. All other systems -- even other IBM operating systems -- were left standing outside. Since z/OS 1.10 it is possible to choose to use either the "z/OS only" or the "quasi standard" in implicit FTPS servers. To support both at the same time is yet not possible.

FTPES is the best compromise to support a wide range of clients. To reduce incompatibilities to the minimum it is the better choice on z/OS. That the connection is not encrypted in the beginning doesn't cause any vulnerabilities. You can switch on TLS/SSL only with the first transmitted FTP command. All what attackers can see is the following: Two systems establish a connection. The client sends AUTH TLS or AUTH SSL to the server. Everything becomes encrypted. Furthermore FTPES allows a transparent solution for migration. FTPES can be configured to accept unencrypted FTP as well as encrypted FTPES--both at the same listening port. In a migration scenario a big plus! You can switch on FTPES parallel to traditional FTP. You migrate client for client. When the last client is switched to FTPES you simply configure your FTPES server to accept from now on only encrypted connection. Old FTP will be denied.

It is easy to switch on FTPES in z/OS' FTP server. Listing 2 shows an excerpt of FTP.DATA -- the FTP configuration of z/OS Communication Server. First it enables the AUTH_TLS extension by the EXTENSION statement. By the SECURE_FTP statement you can decide whether FTPES is the only way to connect (REQUIRED) or FTPES is an optional alternative to traditional FTP (ALLOWED). The last one I recommend for migration scenarios as mentioned before.


EXTENSIONS AUTH_TLS
; For your migration process use
; SECURE_FTP ALLOWED
SECURE_FTP REQUIRED
SECURE_CTRLCONN PRIVATE
SECURE_DATACONN PRIVATE
; CIPHERSUITE SSL_NULL_MD5
; CIPHERSUITE SSL_NULL_SHA
; CIPHERSUITE SSL_RC4_MD5_EX
; CIPHERSUITE SSL_RC4_MD5
; CIPHERSUITE SSL_RC4_SHA
; CIPHERSUITE SSL_RC2_MD5_EX
; CIPHERSUITE SSL_DES_SHA
; CIPHERSUITE SSL_3DES_SHA
CIPHERSUITE SSL_AES_128_SHA
CIPHERSUITE SSL_AES_256_SHA
KEYRING FTPD/FTPSKR

Listing 2: FTPES Parameters in FTP.DATA

With SECURE_CTRLCONN and SECURE_DATACONN we come to a very interesting part of an FTPES configuration. FTP needs two channels two transfer information -- both implemented as a separate dedicated network connection. Credentials for authentication and commands are sent over the control channel. The data (e.g. file contents) are transported by the data channel.

You can often hear fairy tales that FTPS can only encrypt the control but not the data channel of FTP connections. That's nonsense! There might be some lazy products which implement encryption only on the control channel but that doesn't apply to FTPS in general. z/OS' FTP server is not lazy in this manner. It is able to encrypt both FTP channels. SECURE_CTRLCONN specifies the level of security for the control channel. SECURE_DATACONN does the same for the data channel. You can configure here several levels of encryption such as never or always encrypt or chosen by client. For a state of the art security level choose PRIVATE for encryption always. Especially do not set it to CLEAR which indicates that the client shall decide to encipher or not. Keep security under your control and so on server's side.

The CIPHERSUITE statements define allowed combinations of cipher and hash algorithms. Listing 2 lists all supported algorithms. The names of the combinations are very simple to understand. The first information (after SSL) tells the cipher algorithms, e. g. RC2, RC4, DES, AES 128, AES 256, or NULL for no encryption algorithm. By the way the *_EX variant are allowed to export outside the USA. The second part tells the hash algorithm MD5 or SHA for transferring authentication data.

Most of you had already guessed right that the combinations with NULL as cipher are not very useful for a real secure FTPES server. Also the old algorithms DES and RC2 are no good choice. Cryptanalysis against them was already successful. 3DES and RC4 should be used to support old clients only. The best choice to implement an adequate level of security is to use AES. This is the reason why Listing 2 only allows AES. The other algorithms are commented out and are only listed for the sake of completeness.

Last but not least KEYRING sets the keyring to use. It specifies the user (FTPD) and the keyring (FTPSKR) separated by a slash. This argument FTPD/FTPSKR specifies a keyring in RACF. Alternatively a keystore on a HFS or ZFS filesystem can be specified simply by its Unix file name with full path. For example:

/u/ftpd/ftps.kdb


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video