Using security mechanisms

File data transferred between an FTP client and server can be secured with respect to encryption, authentication, and data integrity.

Authentication established using a security mechanism can also be used to make the authorization decision. The FTP security interaction begins with a client telling the server what security mechanism it wants to use with the AUTH command. The server either accepts this mechanism, rejects this mechanism, or, in the case of a server which does not implement the security extensions, rejects the command completely. The server's reply indicates if the client must respond with additional data for the security mechanism to interpret.

Once a security association is established, authentication (which is part of this association) can be used in addition to the standard user ID/password exchange for authorizing a user to connect to the server. A user ID specified by the USER command is always required to specify the identity to be used on the server.

Transport Layer Security (TLS) is an upwardly-compatible successor to Secure Sockets Layer (SSL). SSL is a protocol that performs secure and encrypted TCP transmission. The FTP client supports either SSL or TLS protected sessions, including client authentication. Note that the negotiation of SSL versus TLS is performed by the sockets-layer TLS code and is transparent to FTP.

Many TLS/SSL applications work by having a client connect to one TCP port for unprotected sessions and a separate TCP port for protected ones. FTP supports this mode for compatibility with the original SSL design. However, FTP also provides a more general solution for FTP security, where the client connects to the FTP server on the regular, non-encrypted port and negotiates authentication and encryption options.

FTP assumes that the port configured by the TLSPORT statement (default TLSPORT is 990) is a protected port. An AUTH command is not needed and the client completes the exchange of additional data with the server immediately after a successful connection.

FTP support for SSL/TLS protected sessions is based on the Internet Draft, On Securing FTP with TLS. As of October, 2005, On Securing FTP with TLS has been published as RFC 4217. The RFC level is different from the Internet draft. You can set the TLSRFCLEVEL configuration option to choose which level of On Securing FTP with TLS you want FTP to support.

To use the new RFC 4217 or CCCNONOTIFY function, the client and server must have the same TLSRFCLEVEL value.

Table 1 identifies important differences between the draft level and the RFC level of the TLSRFCLEVEL value.

Table 1. Important differences between the draft, RFC, and CCCNONOTIFY levels
Draft level	RFC level	CCCNONOTIFY level
The server does not support the CCC and AUTH commands when the connection is secured with TLS.	The server supports the CCC and AUTH commands on connections that are secured with TLS but not implicitly secured by connecting to the port that is configured with the TLSPORT statement.	The server supports the CCC command but not the AUTH command on connections that are secured with TLS but not implicitly secured by connecting to the port that is configured with the TLSPORT statement. The server does not issue a TLSshutdown command when it receives the CCC command.
The client does not allow CCc or CProtect clear subcommands during a session that is secured with TLS.	The client allows the CCc and CProtect clear subcommands during a session that is secured with TLS but not implicitly secured by connecting to the port that is configured with the TLSPORT statement.	The client allows the CCc and CProtect clear subcommands during a TLS-secured session that is not implicitly secured by connecting to the port that is configured with the TLSPORT statement. The client does not issue a TLSshutdown command when it sends the CCC command.
The client does not allow an AUTH command to flow during a session that is secured with TLS.	The client allows the AUTH command during a session that is secured with TLS but not implicitly secured by connecting to the port that is configured with the TLSPORT statement.	The client does not allow an AUTH command to flow during a session that is secured with TLS.

The server does not allow the PROT or PBSZ commands to run on a control connection that has been cleared with the CCC command. After a successful CCc subcommand, the client does not allow clear, protect clear, private, and protect private subcommands for the remainder of the session.

There are optional FTP commands and statements for negotiating session security. The following list of the configuration parameters determines whether the client uses a security mechanism to protect the session:

See FTP command — Entering the FTP environment for a description of the start parameters.
```
Start parameters
   -a   TLS
   -a   GSSAPI
   -r   TLS
   -r   GSSAPI
```

See Changing local site defaults using FTP.DATA and the z/OS Communications Server: IP Configuration Reference for a description of the FTP.DATA statements.

FTP.DATA statements
   SECURE_MECHANISM
   SECURE_FTP
   SECURE_CTRLCONN 
   SECURE_DATACONN
   SECUREIMPLICITZOS
   CIPHERSUITE
   KEYRING
   TLSPORT
   TLSRFCLEVEL
   TLSTIMEOUT
   SECURE_PBSZ