Steps for customizing the FTP server for TLS

You can customize the FTP server for TLS, but a better way to implement TLS security is by using AT-TLS.

Perform the following steps to customize the FTP server for TLS:

1. Decide what level of RFC 4217, On Securing FTP with TLS, that you want the server to support.
   • To have the server support On Securing FTP with TLS at the Internet draft level, code the following statement in the server's FTP.DATA configuration file:

     TLSRFCLEVEL DRAFT

     This is the default. The z/OS® FTP server has supported TLS security at this level since V1R2. Code this statement in FTP.DATA to maintain this level of support.
   • To have the server support On Securing FTP with TLS at the RFC 4217 level, code the following statement in the server's FTP.DATA configuration file:

     TLSRFCLEVEL RFC4217

     The RFC On Securing FTP with TLS was published as RFC 4217 in October, 2005. The RFC differs from the Internet draft in its description of the AUTH, CCC, and REIN commands. RFC 4217 is less restrictive than the Internet draft regarding when the AUTH and CCC commands can be sent to the server, and more explicit about the details of the server REIN implementation. For more information, see RFC 4217.
2. Code the following statement in the server's FTP.DATA configuration file to enable the server for TLS:

   EXTENSIONS AUTH_TLS

3. Decide what level of authentication you will use for TLS sessions:
   • Server authentication only
   • Client authentication level 1
   • Client authentication level 2
   • Client authentication level 3

   For more information about server authentication and client authentication, see Secure Socket Layer overview.
4. Create the server key ring database and add the certificates you will need to the server key ring database.
   Every TLS session handshake includes server authentication, so you must always add a certificate for this server to the server key ring database. If a server certificate is self signed, you must also export that certificate to the key ring databases of those clients that will log in using TLS. If a server certificate is signed by a certificate authority (CA), the CA certificate used to sign the server certificate needs to be in the client key ring databases, rather than the server certificate. For more information about server authentication, see Server authentication.

   If you are using client authentication and self-signed certificates, you must import the client certificates into the server key ring database. If a client certificate is signed by a CA, the CA certificate used to sign the client certificate needs to be in the server key ring database, rather than the client certificate. For more information, see Client authentication.

5. Decide whether FTP will implement TLS security or AT-TLS will implement TLS security.
   The default is to have FTP implement TLS security. This setting is customized by using the TLSMECHANISM configuration statement.

   • To configure the FTP server to use AT-TLS for TLS security, code the following statement in FTP.DATA:

     TLSMECHANISM ATTLS

   • To configure the FTP server to implement TLS security by itself, code the following statement in FTP.DATA:

     TLSMECHANISM FTP

     This is the default setting.
6. If using TLSMECHANISM FTP, you must configure the FTP server with a key ring database.
   To configure the FTP server with the name of the key ring database, code the following statement in FTP.DATA:

   KEYRING server-keyring-database

   For information about the KEYRING statement, see z/OS Communications Server: IP Configuration Reference.

7. Decide whether clients logging in to this server should be required to use the TLS protocol.
   The default is to allow the client to decide whether to use TLS. This setting is customized by using the SECURE_FTP configuration statement. You should understand that its setting affects both TLS security behavior and Kerberos security behavior.

   To allow the client to decide whether to use TLS, code the following statement in the server's FTP.DATA configuration file:

   SECURE_FTP ALLOWED

   This is the default setting, and indicates:

   • If the server is enabled for TLS only, clients must either log in using TLS, or with no security mechanism.
   • If the server is enabled for Kerberos only, clients must either log in using Kerberos, or with no security mechanism.
   • If the server is enabled for both TLS and Kerberos, clients can log in using TLS, Kerberos, or with no security mechanism.

   To require that clients log in using a security mechanism, code the following statement in the server's FTP.DATA configuration file:

   SECURE_FTP REQUIRED

   This setting indicates:

   • If the server is enabled for TLS only, clients must log in using TLS.
   • If the server is enabled for Kerberos only, clients must log in using Kerberos.
   • If the server is enabled for both TLS and Kerberos, clients must log in using either TLS or Kerberos.
8. If you do not want to use client authentication, you can code the following statement in the server's FTP.DATA configuration file:

   SECURE_LOGIN NO_CLIENT_AUTH

   This is the default.

   If you do want to use client authentication, the following levels of client authentication are possible:

   • Level 1 authentication is performed by system SSL. The client passes an X.509 certificate to the server. To pass authentication, the Certificate Authority that signed the client certificate must be considered trusted by the server. To use level 1 client authentication, code the following statement in the server's FTP.DATA configuration file:

     SECURE_LOGIN REQUIRED

   • Level 2 authentication provides level 1 authentication, and additionally requires that the client certificate be registered with RACF® (or another SAF compliant security product) and mapped to a user ID. The client certificate received during the SSL handshake is used to query the security product to verify that the certificate maps to a user ID known to the system prior to connection negotiation. To use level 2 client authentication, code the following statement in the server's FTP.DATA configuration file:

     SECURE_LOGIN VERIFY_USER

   • Level 3 authentication provides level 1 and 2 authentication. In addition, it provides the capability to restrict access to the server based on the user ID returned from RACF. If the SERVAUTH class of RACF is active and the server's port profile is defined, a connection is accepted only if the requester's user ID associated with the client certificate is defined in the server's port profile. To use level 3 client authentication, code the following statement in the server's FTP.DATA configuration file:

     SECURE_LOGIN VERIFY_USER

     Also, define the server's port profile in the SERVAUTH class of RACF.

   If you choose to use client authentication, you can also use the client certificate authentication process to eliminate the client login password prompt so that a client supplies only the login user ID to establish the session. The certificate received from the client must be registered in the security product and must be associated with the login user ID. You can use the RACDCERT ADD command to register and associate the certificate. If either the certificate is not registered or is not associated with the user ID, you will be prompted for a password.

   If you do not want to use the client authentication process to eliminate the client password prompt, you can code the following statement in the server's FTP.DATA configuration file:

   SECURE_PASSWORD REQUIRED

   This is the default.

   If you want to use the client authentication process to eliminate the client password prompt, along with your client authentication statement (either SECURE_LOGIN REQUIRED or SECURE_LOGIN VERIFY_USER), code the following statement in the server's FTP.DATA configuration file:

   SECURE_PASSWORD OPTIONAL

9. If you specified TLSMECHANISM ATTLS, configure the AT-TLS policy for the FTP server.
   To configure AT-TLS, see Configuring the server system.

   Requirements:

   • The FTP server is a controlling application. For more information about controlling applications, see Advanced application considerations.

     Code a TTLSEnvironmentAdvancedParms statement with the ApplicationControlled and SecondaryMap parameters; both parameters should specify the value On. The ApplicatonControlled parameter allows FTP to start and stop TLS security on a connection. The SecondaryMap parameter enables active or passive data connections to use the AT-TLS policy that is used for the control connection. You do not need to code any additional TTLSRule statements for the data connections.

   • The FTP server requires that the HandshakeRole parameter with the value Server or ServerWithClientAuth be coded on the TTLSEnvironmentAction statement. If the SECURE_LOGIN statement is coded in FTP.DATA with the parameters REQUIRED or VERIFY_USER, the HandshakeRole parameter value must be ServerWithClientAuth.
   • The TTLSRule statement for the FTP server requires the Direction parameter with the value Inbound.

   A sample Policy Agent AT-TLS configuration showing the required policy configuration statements for AT-TLS is as follows:

      TTLSGroupAction  secure_ftp_server_group
      {
         TTLSEnabled On
      }
      TTLSEnvironmentAction secure_ftp_server_env
      {
         TTLSKeyringParms
         {
            Keyring server-keyring-database
         }
         HandshakeRole Server       # When Secure_Login NO_CLIENT_AUTH is coded
         #HandshakeRole ServerWithClientAuth # When Secure_Login Required or Verify_User is coded
         TTLSEnvironmentAdvancedParms
         {
            ApplicationControlled On
            SecondaryMap  On
         }
         TTLSCipherParmsRef   ftp_server_ciphers     # Used to customize ciphersuites for the FTP 
                                                     # server
      }
   TTLSCipherParms ftp_server_ciphers 
   {
      # Sample ciphers.  Should be customized!
      V3CipherSuites TLS_RSA_WITH_AES_256_CBC_SHA
      V3CipherSuites TLS_RSA_WITH_3DES_EDE_CBC_SHA
      V3CipherSuites TLS_RSA_WITH_NULL_SHA 
   }
   
      TTLSRule secure_ftp_server_rule
      {
         LocalPortRange 21                   # This should be set to the port the FTP server is
                                             #  listening on
         Direction Inbound
         TTLSGroupActionRef secure_ftp_server_group
         TTLSEnvironmentActionRef secure_ftp_server_env
      }

   Tip: You can enable additional security settings with AT-TLS, such as LDAP servers and handshake timeout values. The configuration used in the example is the minimum required to allow the FTP server to use AT-TLS. You can add additional configuration statements.
10. Decide which cipher algorithms the server should use to encipher data transfers and to encipher control information.
    FTP and AT-TLS support TLS through the system SSL cryptographic services base element of z/OS. System SSL supports multiple cipher algorithms that provide both encryption and data authentication (that is, data integrity). Encryption scrambles the data so it is transferred confidentially and cannot be interpreted without a special key. Data authentication algorithms ensure the data was not modified during transfer. Some of the supplied cipher algorithms provide only data authentication, and some provide both encryption and authentication. Be aware that the actual cipher algorithm used for the session is determined by a negotiation between the server and client. For example, if you configure an FTP server to use the Triple DES encryption, SHA authentication algorithm, but the client does not support that cipher algorithm, Triple DES encryption, SHA authentication will not be used for sessions between the server and that client.

    If using TLSMECHANISM FTP, select which cipher algorithms you prefer to use by coding a CIPHERSUITE configuration statement in the FTP.DATA file for each cipher algorithm the server can use. For a list of the cipher algorithms you can specify on the CIPHERSUITE statement, see z/OS Communications Server: IP Configuration Reference. List the CIPHERSUITE statements in FTP.DATA in the order of preference, your most preferred cipher algorithm being first. System SSL will negotiate a cipher algorithm with the server on behalf of the client using the same order of preference as is indicated by the order of CIPHERSUITE statements in FTP.DATA.

    If you specify TLSMECHANISM ATTLS, select which cipher algorithms you want to use by coding a TTLSCipherParms configuration statement to specify the cipher algorithms that the server can use. For a list of the cipher algorithms you can specify with the TTLSCipherParms statement, see z/OS Communications Server: IP Configuration Reference. List the ciphers in the order of preference, your most preferred cipher algorithm first. The cipher algorithm is negotiated with the server on behalf of the client using the same order of preference as indicated by the order of the TTLSCipherParms statement.

    Restrictions:

    • Only RSA key exchange is supported.
    • The following algorithms are subject to export regulations and might not be available to your system:
      • Triple DES encryption, SHA authentication
      • RC4 (128-bit) encryption, SHA authentication
      • RC4 (128-bit) encryption, MD5 authentication
      • AES (128-bit and 256-bit) encryption, SHA authentication

    Guideline: The default ciphers used by System SSL support a null cipher, which has no encryption or authentication. A TTLSCipherParms statement or CIPHERSUITE statement should be coded to remove the null cipher from the list of acceptable ciphers.
11. Decide the level of security for the data connection.
    You can choose to require enciphered data transfers, or to allow the client to decide the level of security for data transfers. The default is to allow the clients to decide the level of security.

    This setting is customized by using the SECURE_DATACONN configuration statement. You should understand that its setting affects both TLS security behavior and Kerberos security behavior.

    If you want the server to require that data is transferred raw with no cipher algorithm applied to the data and that clients attempting to use ciphers are rejected, code the following statement in the server's FTP.DATA configuration file:

    SECURE_DATACONN NEVER

    If you want the client to decide whether data is transferred raw or enciphered, you can code the following statement in the server's FTP.DATA configuration file:

    SECURE_DATACONN CLEAR

    This is the default.

    For TLS, the client decides whether data is enciphered or not. If it indicates it should be enciphered, the cipher algorithm is negotiated between the server and the client using TLS protocols. For Kerberos, the client can specify whether data is transferred raw, integrity protected only, or both integrity and privacy protected.

    If you want the server to require that data is transferred enciphered and that clients attempting to send raw data are rejected, code the following statement in the server's FTP.DATA configuration file:

    SECURE_DATACONN PRIVATE

    For TLS, the cipher algorithm is negotiated between the server and the client using TLS protocols. For Kerberos, the data must be transferred using both integrity and privacy protection. Clients attempting to send data that is only integrity protected are rejected.

12. Decide whether the server requires session reuse when SSL/TLS is used to protect the control and data connections.
    By default, the server is enabled to reuse either of the following SSL session IDs on the data connections within an FTP session:

    • The SSL session ID of the control connection
    • The SSL session ID of a previous data connection

    This setting is customized by using the SECURE_SESSION_REUSE configuration statement.

    • To enable the server to reuse either of the following SSL session IDs on the subsequent data connections within an FTP session, code ALLOWED on the SECURE_SESSION_REUSE statement in the FTP.DATA configuration file of the server:
      • The SSL session ID of the control connection
      • The SSL session ID of a previous data connection

      This is the default.

    • To require the server to reuse the SSL session ID of the control connection on the subsequent data connections within an FTP session, code REQUIRED on the SECURE_SESSION_REUSE statement in the FTP.DATA configuration file of the server.

      This setting might cause data connections and FTP transfers to fail when the remote side does not support reusing the session ID.

    For information about the SECURE_SESSION_REUSE statement, see z/OS Communications Server: IP Configuration Reference.

13. For information about configuring your security product for TLS, see TLS/SSL security.