Cleo Technical Support

Cleo 3270 Communications Encryption

The Cleo Transaction Processor and traditional TN3270 software support TN3270E as well as SSL for communications and secure encryption to one or more mainframes.

3270 Terminals and Protocol

The IBM 3270 is a class of terminals made by IBM since 1972 (known as "display devices") normally used to communicate with IBM mainframes. As such, it was the successor to the IBM 2260 display terminal. Due to the text color on the original models, these terminals are informally known as green screen terminals. Unlike common serial ASCII terminals, the 3270 minimizes the number of I/O interrupts required by accepting large blocks of data known as data streams, and uses a high speed proprietary communications interface, using coax cable.

IBM stopped manufacturing terminals many years ago, but the IBM 3270 protocol is still commonly used via terminal emulation to access some mainframe-based applications. Accordingly, such applications are sometimes referred to as green screen applications. Use of 3270 is slowly diminishing over time as more and more mainframe applications acquire Web interfaces, but some web, IVR and call center applications use the technique of "screen scraping" to capture old screens and transfer the data to modern front-ends. Today, many sites such as call centers still find the "green screen" 3270 interface to be more productive and efficient than spending resources to replace them with more modern systems.

What is a 3270 Data Stream?

3270 devices include a series of display devices, communications controllers, and printers that connect to an IBM mainframe. They support a special type of data stream, which is called the 3270 data stream. This data stream allows applications to include control characters that instruct the receiving device how to format or display the information. The control characters allow the application to use the entire screen, as opposed to a single command line, to display information and to receive input from various areas of the screen (called partitions).

SNA 3270

SNA 3270 refers to 3270 data streams that are transported from the source to the destination using the SNA protocol. With SNA 3270, the data stream is transmitted over an LU-to-LU session between logical units. LU types 2 and 3 use only SNA 3270 data streams. LU types 6.1 and 6.2 use the SNA 3270 data stream in addition to other types of data streams.

With SNA 3270, the mainframe application creates a 3270 data stream using 3270 commands, the data stream is transported over an SNA network, and the data is displayed on a 3270-compliant device.

TN3270

TN3270 is a protocol that defines how to transport 3270 data streams over a TCP/IP network. TN3270 was originally defined in RFC 1576 and is based on the Telnet protocol. The difference between a Telnet session and a TN3270 session is that a Telnet session uses the ASCII character set and sends a line of data at a time and a TN3270 session uses the EBCDIC character set and sends a block of data (a screen refresh) at a time.

The following elements work together to enable TN3270 communication:

  • The end stations run a TN3270 client. The client emulates a 3270 display device. This client, in the case of the Cleo software, runs on a server and programmatically interfaces with the mainframe.
  • The client accesses a TN3270 server over an IP network.
  • The TN3270 server converts the TN3270 data stream to SNA 3270 and passes the data to the mainframe. The TN3270 server resides on either the mainframe, in which case it is considered an inboard server, or a front-end processor (FEP) such as a controller or a network device, in which case it is considered an outboard server.
  • The mainframe provides Virtual Telecommunications Access Method (VTAM) and the mainframe application that the user is attempting to access.

In an SNA 3270 network, the user is known by the LU name. In a TCP/IP network, the user is known by an IP address. One of the tasks of the TN3270 server is to provide a correlation between these two addresses. This correlation allows the SNA applications to maintain the LU requirements and allows the network to use IP.

TN3270E

TN3270, as defined by RFC 1576, does not address several functions that are required to make the TN3270 server a viable migration solution. To address this problem, TN3270E was defined under RFC 2355 (which made obsolete RFC 1647). TN3270E added the following functions:

  • Emulation of 328x printers: All IBM-type printers accept both LU 1 and LU 3 printer streams because a printer may be shared between multiple IBM host applications, such as JES and CICS. The JES can be configured for LU 1 data streams and the CICS can be configured for LU 3 data streams. A TN3270 server cannot function properly with mainframe applications and 3270 printers if it does not allow a mix of LU 1 and LU 3 data streams.
  • Client request of a particular name: Many host applications behave differently depending on the network name of the terminal. In the case of printer emulation, many host applications use a method of predefining printer destinations. It is important that a Telnet client is allowed to request that a connection be associated with a specific 3270 device name.
  • 3270 ATTN key: The 3270 ATTN key is interpreted by many host applications in an SNA environment as an indication that the user wants to interrupt the execution of the current process. The Telnet Interrupt Process (IP) command was defined for this purpose and was used in implementing support for the 3270 ATTN key. TN3270E supports the 3270 ATTN key in both the client and server:
  • SNA positive/negative responses: A positive response indicates that the previously received data was successfully processed. A negative response is used to indicate that an error has occurred while processing the previously received data; this error may be caused by the host application building a 3270 data stream that contains an invalid command or by a mechanical error at the client side. Support for positive/negative responses is important in printer emulation, but it is also useful for some terminal applications.
  • Client access to BIND information: The BIND image contains a detailed description of the session between the Telnet server and the host application. TN3270 provided no way for the client to access session information. Certain clients require access to the BIND information so that they can determine the format of the data they are to receive. For example, printer clients require access to BIND information to distinguish whether the data stream is LU 1 or LU 3.

SSL and TLS

Transport Layer Security (TLS) and its better known predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide security and data integrity for communications over TCP/IP networks such as the Internet. TLS and SSL encrypt the segments of network connections at the Transport Layer end-to-end. Several versions of the protocols are in wide-spread use in applications like web browsing, electronic mail, Telnet, Internet faxing, and voice-over-IP (VoIP).

In typical client usage, TLS/SSL authentication is unilateral: only the server is authenticated (the client knows the server's identity), but not vice versa (the client remains unauthenticated or anonymous). At the client level, the client validates the server's certificate — i.e., checked the digital signatures of the server certificate's issuing CA-chain (chain of Certification Authorities that guarantee bindings of identification information to public keys — see public key infrastructure).

TLS/SSL involves three basic phases:

  1. Peer negotiation for algorithm support
  2. Key exchange and authentication
  3. Symmetric cipher encryption and message authentication

During the first phase, the client and server negotiate cipher suites, which determine the ciphers to be used, the key exchange and authentication algorithms, as well as the message authentication codes (MACs). The key exchange and authentication algorithms are typically public key algorithms. The message authentication codes are made up from cryptographic hash functions using the HMAC construction for TLS, and a non-standard pseudorandom function for SSL.

The Cleo "client" supports the following encryption algorithms:

  • DES-CBC
  • DES-EDE3-CBC
  • IDEA-CBC
  • RC4
  • RC2-CBC
  • AES-128-CBC
  • AES-192-CBC
  • AES-256-CBC
  • MD2
  • RSA-MD2
  • MD5
  • RSA-MD5
  • SSL2-MD5
  • SSL3-MD5
  • SHA1
  • RSA-SHA1
  • SSL3-SHA1
  • RSA-SHA1-2
  • DSA
  • DSA-SHA1
  • DSA-SHA1-OLD
  • DSS1
  • SSL_AES_256_SHA
  • SSL_AES_128_SHA
  • SSL_3DES_SHA

The SSL protocol was originally developed by Netscape. Version 1.0 was never publicly released; version 2.0 was released in February 1995 but "contained a number of security flaws which ultimately led to the design of SSL version 3.0", which was released in 1996 (Rescorla 2001). This later served as the basis for TLS version 1.0, an Internet Engineering Task Force (IETF) standard protocol first defined in RFC 2246 in January 1999. Visa, MasterCard, American Express and many leading financial institutions have endorsed SSL for commerce over the Internet.