Secure and non-secure connections using a single Telnet port

A single port can be used to support a mix of secure and non-secure traffic. The port has the designation SECUREPORT or TTLSPORT. To support the configuration of various security policies for a single port, the SECUREPORT or TTLSPORT designation indicates that the port can use TLS/SSL, but the port does not have to use TLS/SSL.

Telnet supports both negotiated and non-negotiated TLS/SSL. Negotiated TLS/SSL is an IETF-defined extension to the TN3270 protocol. With negotiated TLS/SSL, the decision to use TLS/SSL for a connection is based on the outcome of a negotiation between the Telnet client and server using TN3270 protocols. This negotiation is performed after the Telnet connection is established, and if TLS/SSL is negotiated, the TLS/SSL handshake is performed. With non-negotiated TLS/SSL, a TLS/SSL handshake is required immediately after the connection is established. A single port can concurrently use both negotiated and non-negotiated TLS/SSL connections.

Figure 1 shows a single Telnet port that allows a mix of secure and non-secure traffic. Intranet clients are not required to be secure. All clients connecting from the Internet are required to use SSL. Both intranet and Internet clients connect to the port designated as SECUREPORT (port 23 in this example). In this scenario, IPSec AH protocol is used for authentication between the user's PC and the firewall. The firewall is open for port 23 for traffic that is authenticated with only IPSec. The firewall discards traffic for port 23 that IPSec cannot authenticate. In this scenario, packet filtering without IPSec cannot be used at the firewall that separates the intranet and the Internet to control access on the basis of port, because only one port is used. Without IPSec AH, all access control checks are deferred to Telnet. The additional security provided by IPSec at the firewall protects the z/OS® server from unauthorized access attempts and denial-of-service attacks by hosts outside the VPN.