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.
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
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
