Secure FTP Overview

1. April 2009 Martin Trinkler Agenda

Supported FTP security functions by z/OS FTP Client with SOCKS proxy protocol Secure Sockets Layer/Transport Layer Security (SSL/TLS) Application Transparent-TLS (AT-TLS) IP Security (IPSec) Kerberos security Configuration of FTP native TLS security Firewall Restrictions Related publications Q & A © Company Insurance Zurich

3/9/2009 Secure FTP Overview 2 Supported FTP security functions by z/OS

sFTP (OpenShell procedure) FTP Client with SOCKS proxy protocol Secure Sockets Layer/Transport Layer Security (SSL/TLS) Application Transparent-TLS (AT-TLS) IP Security (IPSec) Kerberos security © Company Insurance Zurich

3/9/2009 Secure FTP Overview 3 sFTP (OpenShell procedure)

The SSH File Transfer Protocol (sometimes called Secure File Transfer Protocol or SFTP) is a network protocol that provides file transfer and manipulation functionality over any reliable data stream. It is typically used with version two of the SSH protocol (TCP port 22) to provide secure file transfer and not using FTP protocols as described in RFC959 and its related RFCs. FTP with SOCKS proxy protocol

The FTP client has to access the FTP server indirectly by passing through a SOCKS proxy server. The client must use the SOCKS protocol to successfully navigate through the proxy server. The client must be able to determine which servers it must contact using the SOCKS protocol. These servers are specified in a SOCKS configuration file that the client reads to make this determination. The SOCKSCONFIGFILE statement in the client’s FTP.DATA file is used to point the client to the configuration file where these servers are identified © Company Insurance Zurich

3/9/2009 Secure FTP Overview 5 Configuration example

FTP.DATA statement SOCKSCONFIGFILE

Config File: SOCKD @=192.168.20.11 172.14.0.0/16 DIRECT 10.0.0.0/8 DIRECT 0.0.0.0 0.0.0.0 Secure Sockets Layer/Transport Layer Security (SSL/TLS) 1/2

SSL/TLS provides: – data privacy – data integrity – server and client authentication based upon a Public Key Infrastructure (PKI) method PKI requires a server generated public/private key pair used during negotiations. PKI requires that data encrypted with the public key be decrypted by only the private key and vice versa. This is called an asymmetric encryption method because different keys are used at each end of the secure connection © Company Insurance Zurich

3/9/2009 Secure FTP Overview 7 Secure Sockets Layer/Transport Layer Security (SSL/TLS) 2/2

PKI method of encryption is used for SSL parameter negotiations The most important items negotiated is the encryption algorithm to be used during data transmission The algorithm chosen will be one that uses the same key at each end of the secure connection (symmetric encryption) © Company Insurance Zurich

3/9/2009 Secure FTP Overview 8 SSL Handshake 1/3 Secure Sockets Layer/Transport Layer Security

1. The client sends a CLIENT_HELLO command to the server, which includes: • The highest SSL and TLS version supported by the client. • Ciphers supported by the client. The ciphers are listed in order of preference. • Data compression methods that are supported by the client. • The session ID. If the client is starting a new SSL session, the session ID is 0. • Random data that is generated by the client for use in the key generation process. 2. The server sends a SERVER_HELLO command to the client, which includes: • The SSL or TLS version that will be used for the SSL session. • The cipher that will be used for the SSL session. • Data compression method that will be used for the SSL session. SSL Version 3 and TLS have no compression algorithms defined at this time. • The session ID for the SSL session. • Random data that is generated by the server for use in the key generation process. © Company Insurance Zurich

3/9/2009 Secure FTP Overview 9 SSL Handshake 2/3 Secure Sockets Layer/Transport Layer Security

3. The server sends CERTIFICATE command. This command includes the server's certificate and, optionally, a chain of certificates beginning with the certificate of the certificate authority (CA) that assigned the server's certificate. 4. The server sends SERVER_DONE command. This command indicates that the server has completed this phase of the SSL handshake. If client authentication will be performed, additional commands flow between the client and the server following the SERVER_DONE command. 5. The client sends CLIENT_KEY_EXCHANGE command. This command contains the premaster secret that was created by the client and was then encrypted using the server's public key. Both the client and the server generate the symmetric encryption keys on their own using the premaster secret and the random data that is generated from the SERVER_HELLO and CLIENT_HELLO commands. 6. The client sends CHANGE_CIPHER_SPEC command. This command indicates that the contents of subsequent SSL record data sent by the client during the SSL session will be encrypted. The 5-byte SSL record headers are never encrypted. 7. The client sends FINISHED command. This command includes a digest of all the SSL handshake commands that have flowed between the client and the server up to this point. This command is sent to validate that none of the commands sent previously, which flow between the client and the server unencrypted, were altered in flight. © Company Insurance Zurich

3/9/2009 Secure FTP Overview 10 SSL Handshake 3/3 Secure Sockets Layer/Transport Layer Security

8. The server sends CHANGE_CIPHER_SPEC command. This command indicates that all subsequent data sent by the server during the SSL session will be encrypted. 9. The server sends FINISHED command. This command includes a digest of all the SSL handshake commands that have flowed between the server and the client up to this point. © Company Insurance Zurich

3/9/2009 Secure FTP Overview 11 Server authentication Secure Sockets Layer/Transport Layer Security

Server authentication is the minimum amount of security provided by SSL The server sends its public key, a signature and additional information so the client can confirm the identity of the server The complete package is called a digital certificate which conforms to the X.509 standard. A certificate can be self-signed or created by a well-known Certificate Authority (CA) Most client key rings have been primed with several well-known CA’s certificates The self-signed certificate needs to be added to the client’s list of signer certificates The gskkyman utility or RACF Common Keyring support can be used to manage the keys and certificates. © Company Insurance Zurich

3/9/2009 Secure FTP Overview 12 Client authentication Secure Sockets Layer/Transport Layer Security

Client authentication provides additional authentication and access control by checking client certificates at the server. The server authenticates the client by receiving the client’s certificate during the SSL handshake Three different levels of client authentication are available. Level 1 – Client authentication is done by SSL using a gskkyman or a RACF key ring. – The CA certificate in RACF must be set to TRUST and connected to the appropriate RACF key ring Level 2 – Additionally to level 1 authentication the client certificate must be registered with RACF and mapped to a user ID. Level 3 – Authentication provides, in addition to level 1 and level 2 support, the capability to restrict access to the server based on the user ID returned from RACF – The SERVAUTH RACF class is used to restrict access to the server based on client user ID © Company Insurance Zurich

3/9/2009 Secure FTP Overview 13 Encryption algorithms Secure Sockets Layer/Transport Layer Security

After authentication is performed, the client and server must agree on a symmetric encryption method and generate a single encryption key to use for data encryption using the PKI method of encryption. During the SSL handshake the client sends a list of encryption algorithms it is willing to use. The server submits its list and the SSL subsystem picks an algorithm all parties support. Once the symmetric encryption algorithm and a single encryption key are chosen, all data exchanges use this algorithm and key instead of the PKI method of encryption System SSL uses the Integrated Cryptographic Service Facility (ICSF) if it is available. ICSF provides hardware cryptographic support which will be used instead of the System SSL software algorithms. © Company Insurance Zurich

3/9/2009 Secure FTP Overview 14 FTP with AT-TLS security support 1/2

Application Transparent TLS (AT-TLS) provides TLS support for existing clear-text socket applications without requiring any application changes. AT-TLS support is policy-driven and is managed by a Policy Agent. The FTP server and client can use AT-TLS to manage TLS security. FTP is a controlling AT-TLS application which means that the application starts and stops security on the connection, through the AT-TLS mechanism FTP relies on the definition of AT-TLS policies that Policy Agent downloads into the TCP/IP stack © Company Insurance Zurich

3/9/2009 Secure FTP Overview 15 FTP with AT-TLS security support 2/2

AT-TLS has considerable advantages over standard TLS/SSL for the FTP environment:

Certificate labels, thus eliminating the need to rely only on the presence of a default certificate in a key ring Certificate revocation lists (CRLs) Support SSL Session Key Refresh Trace decrypted SSL data for FTP in a data trace Receive more detailed diagnostic messages in syslogd © Company Insurance Zurich

3/9/2009 Secure FTP Overview 16 FTP with IPSec

IPSec is a suite of protocols and standards defined by the Internet Engineering Task Force (IETF) to provide an open architecture for security at the IP networking layer of TCP/IP. It is the most commonly used protocol for implementing a Virtual Private Network (VPN). Because IPSec works at the IP networking layer, IPSec can be used to provide security for any TCP/IP application without modification. If necessary, applications can have their own additional security features on top of the underlying IPSec security. With a VPN connection native FTP can be used for secure data transfer © Company Insurance Zurich

3/9/2009 Secure FTP Overview 17 Kerberos security

The Kerberos protocol is designed to operate across organizational boundaries A Kerberos-based network authentication service enables applications that use Kerberos to use a Kerberos ticket for authentication instead of a user ID and password FTP server supports single sign-on for Kerberos connections The FTP client must be enabled to use Kerberos The FTP client can be enabled to use either TLS or Kerberos, but not both at the same time © Company Insurance Zurich

3/9/2009 Secure FTP Overview 18 Configuration of FTP native TLS security 1/2 (z/OS client to z/OS server with self-signed CA certificate)

Create a shared key ring (used by client and server) Generate a RACF CA certificate Generate a RACF SITE certificate Connect both certificates to the shared key ring Permit access for the FTP server and FTP users to the private key of the shared SITE certificate in the key ring Permit access to LIST the certificates (IRR.DIGTCERT.LIST) Permit access for the FTP server and FTP users to the shared key ring © Company Insurance Zurich

3/9/2009 Secure FTP Overview 19 Configuration of FTP native TLS security 2/2 (z/OS client to z/OS server with self-signed CA certificate)

Update the FTP.DATA for the server – EXTENSIONS AUTH_TLS – TLSMECHANISM FTP – KEYRING TCPIP/SharedRing1 – CIPHERSUITE SSL_RC4_MD5_EX ; 03 – CIPHERSUITE SSL_RC4_MD5 ; 04 – CIPHERSUITE SSL_3DES_SHA ; 0A – CIPHERSUITE SSL_DES_SHA ; 09 – CIPHERSUITE SSL_NULL_MD5 ; 01 – CIPHERSUITE SSL_NULL_SHA ; 02 – SECURE_FTP ALLOWED © Company Insurance Zurich

3/9/2009 Secure FTP Overview 20 Firewall Restrictions

FTP passive mode (FWFRIENDLY) – data connections are set up from the FTP client Allow encrypted control connections – some firewalls run more or less intensive checks on the traffic within the control connections © Company Insurance Zurich

3/9/2009 Secure FTP Overview 21 Related publications

Redbook Communications Server for z/OS V1R9 TCP/IP Implementation Volume 4: Security and Policy-Based Networking SG24-7535-00 z/OS Communications ServerIP Configuration Guide SC31- 8775-13 RFC 4217 http://tools.ietf.org/html/rfc4217 © Company Insurance Zurich

3/9/2009 Secure FTP Overview 23 Thank you

zurich.com