z/os v2r3 communications server content preview

© 2017 IBM Corporation

z/OS V2R3 Communications Server: Content Preview

Gus Kassimis - [email protected] Reynolds - [email protected] 29, 2017

© 2017 IBM Corporation2

TrademarksThe following are trademarks of the International Business Machines Corporation in the United States and/or other countries.

The following are trademarks or registered trademarks of other companies.

* Registered trademarks of IBM Corporation

* All other products may be trademarks or registered trademarks of their respective companies.

Notes: Performance is in Internal Throughput Rate (ITR) ratio based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput that any user will experience will vary depending upon considerations such as the amount of multiprogramming in the user's job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve throughput improvements equivalent to the performance ratios stated here. IBM hardware products are manufactured from new parts, or new and serviceable used parts. Regardless, our warranty terms apply.All customer examples cited or described in this presentation are presented as illustrations of the manner in which some customers have used IBM products and the results they may have achieved. Actual environmental costs and performance characteristics will vary depending on individual customer configurations and conditions.This publication was produced in the United States. IBM may not offer the products, services or features discussed in this document in other countries, and the information may be subject to change without notice. Consult your local IBM business contact for information on the product or services available in your area.All statements regarding IBM's future direction and intent are subject to change or withdrawal without notice, and represent goals and objectives only.Information about non-IBM products is obtained from the manufacturers of those products or their published announcements. IBM has not tested those products and cannot confirm the performance, compatibility, or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.Prices subject to change without notice. Contact your IBM representative or Business Partner for the most current pricing in your geography.

IBM*IBM Logo*

Adobe, the Adobe logo, PostScript, and the PostScript logo are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, and/or other countries. IT Infrastructure Library is a registered trademark of the Central Computer and Telecommunications Agency which is now part of the Office of Government Commerce. Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo, Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. ITIL is a registered trademark, and a registered community trademark of the Office of Government Commerce, and is registered in the U.S. Patent and Trademark Office. UNIX is a registered trademark of The Open Group in the United States and other countries. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates. Cell Broadband Engine is a trademark of Sony Computer Entertainment, Inc. in the United States, other countries, or both and is used under license therefrom. Linear Tape-Open, LTO, the LTO Logo, Ultrium, and the Ultrium logo are trademarks of HP, IBM Corp. and Quantum in the U.S. and other countries.


Agenda

• z/OS Encryption Readiness Technology (zERT)• z/OS mail updates• Wildcard support for jobnames on PORT &

PORTRANGE statements• AT-TLS currency with System SSL• Miscellaneous V2R3 topics• Configuration Assistant Updates• Full VTAM Internal Trace (VIT) control• Appendix: Additional Details on z/OS V2R3 CS Content

and Other Topics


IBM's statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM's sole discretion. Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our products remain at our sole discretion.


z/OS Encryption

Readiness

Technology (zERT)


Encrypting Network Traffic Becoming standard practice even within trusted networks§ Encryption of network traffic is a key part of the strategy to provide

comprehensive data protection§ Encryption of network traffic quickly becoming a requirement for all organizations § For many organizations, shifting from a selective encryption policy to a

comprehensive encrypt all network traffic strategy and policy§ Organizations struggle with questions such as:

1. What data should be encrypted?2. Where should encryption occur?3. Who is responsible for encryption?4. How do I know that my network traffic is encrypted using my entrerprise

security standards?


Background: Encrypting TCP/IP network traffic on z/OS

z/OS provides 4 mechanisms to protect TCP/IP traffic:

TLS/SSL direct usage• Application is explicitly coded to use these• Configuration and auditing is unique to each application• Per-session protection• TCP only

Application Transparent TLS (AT-TLS)• TLS/SSL applied in TCP layer as defined by policy• Configured in AT-TLS policy via Configuration Assistant• Auditing through SMF 119 records• Typically transparent to application • TCP/IP stack is user of System SSL services

Virtual Private Networks using IPSec and IKE• “Platform to platform” encryption• IPSec implemented in IP layer as defined by policy• Auditing via SMF 119 records at tunnel level only• Completely transparent to application• Wide variety (any to all) of traffic is protected• IKE negotiates IPSec tunnels dynamically

Secure Shell using z/OS OpenSSH• Mainly used for sftp on z/OS, but also offers secure terminal

access and TCP port forwarding• Configured in ssh configuration file and on command line• Auditing via SMF 119 records• TCP only

TCP/IP

CommServer

z/OS

Application

JSSE

DB2, CICS, IMS Connect, Guardium, FTP, TN3270, JES/NJE, RACF RRSF, ….

AT-TLS

Prot

ecte

d

Prot

ecte

dTLS/SSL

System SSL

System SSL

1

2

IPSec

Systems

Prot

ecte

d

Any application or subsystem

VPN

IKE

IPSec3

Open SSH

SSH

Prot

ecte

d

4

MQ, CICS, Connect:Direct, …

WAS, Java applications

1

2

3

4

sftp, TCP appls (port forwarding)


Background (cont)

Given all these mechanisms, configuration methods and variation in audit detail… § How can I tell…

• Which traffic is being protected (and which is not)?• How is that traffic being protected?

- Security protocol?- Protocol version?- Cryptographic algorithms?- Key lengths?- …and so on

• Who does on the traffic belong to in case I need to follow up with them?

§ How can I ensure that new configurations adhere to my company’s security policies?

§ Once I’ve answered the above questions, how can I provide the information to my auditors or compliance officers?

§ Many factors driving these questions:• Regulatory compliance (corporate, industry,

government)• Vulnerabilities in protocols and algorithms• Internal audits• …and so on

TCP/IP

CommServer

z/OS

Application

DB2, CICS, IMS Connect, Guardium, FTP, TN3270, JES/NJE, RACF RRSF, ….

AT-TLS

Prot

ecte

d

Prot

ecte

dTLS/SSL

System SSL2

IPSec

Systems

Prot

ecte

d

Any application or subsystem

VPN

IKE

IPSec3

Open SSH

SSH

Prot

ecte

d

4

MQ, CICS, Connect:Direct, …

WAS, Java applications sftp, TCP

appls (port forwarding)

JSSE

System SSL1


A z/OS network administrator can discover and audit the network encryption attributes associated with z/OS TCP and Enterprise Extender traffic by analyzing new SMF records.

§ zERT positions the TCP/IP stack as a central collection point and repository for cryptographic security attributes for:• TCP connections that are protected by TLS, SSL, SSH, IPsec or are unprotected• Enterprise Extender connections that are protected by IPsec or are unprotected

§ Two methods for discovering the security sessions and their attributes:• Stream observation (for TLS, SSL and SSH) – the TCP/IP stack observes the protocol

handshakes as they flow over the TCP connection• Advice of the cryptographic protocol provider (System SSL, OpenSSH, TCP/IP’s IPsec support)

§ Attributes are collected on a per-connection basis§ Reported through a new SMF 119 record (subtype 11) via:

• SMF and/or• New SYSTCPER real-time NMI service

Introducing z/OS Encryption Readiness Technology (zERT)


zERT connection detail record§ Written at various events in a TCP or EE

connection’s life:• Connection Initiation (event type 1)

- Describes protection state when connection was created (for TCP, state as established within the first 10 seconds of the connection’s life)

- Not usually written for short-lived TCP connections

• Protection State Change (event type 2)Describes significant changes in protection state (security session added, deleted, or modified)

• Connection Termination (event type 3)- Describes protection state when connection

terminated- Has an accompanying Connection Initiation record

• Short Connection Termination (event type 4)- Describes protection state when connection

terminated- Written for short-lived TCP connections (less than 10

seconds long)

§ Also written when zERT is enabled (5) or disabled (6). Event type is the only zERTinformation in these records.

SMF 119 subtype 11 record – Comprehensive network encryption information for TCP/IP and Enterprise Extender traffic


SMF 119 subtype 11 record (cont)

What is collected and recorded?§ Attributes of the connection and its security sessions

§ Significant attributes like protocol version, cryptographic algorithms, key lengths, etc. Changes in these cause a protection state change record to be written if they change

§ Other attributes like protocol session identifiers, session or certificate expiry data and certificate serial numbers are recorded for informational purposes only. When recorded, the values of such attributes are taken at the time the SMF record is written. Changes in these attributes do not constitute a significant change and will not result in the creation of a change event record

§ zERT does not collect, store or record the values of secret keys, initialization vectors, or any other secret values that are negotiated or derived during cryptographic protocol handshakes


SMF 119 subtype 11 record (cont)

Section-by-section content (1 of 4):


SMF 119 subtype 11 record (4 of 6)



SMF 119 subtype 11 record (5 of 6)



Summary

§ There is a growing need to be able to identify and enumerate the cryptographic protection attributes for network traffic for key workloads on z/OS systems

§ With zERT, a z/OS network administrator can discover and audit the network encryption attributes associated with TCP and Enterprise Extender traffic by analyzing new SMF records.

§ zERT positions the z/OS TCP/IP as a central collection point and repository for those attributes. The attributes can be written as SMF 119 subtype 11 records to one or both of:

• SMF• SYSTCPER real-time NMI service

§ With zERT discovery and reporting in place, more advanced capabilities for analyzing z/OS network cryptographic protection become possible

Stay tuned for more information on zERT in a future CAP Education Session!


z/OS Mail Updates


Statement of Direction: z/OS Communications Server Internet mail applications: Sendmail and SMTPD (Issued July 28, 2015)

As previously announced in Hardware Announcement 114-009, dated February 24, 2014, the Simple Mail Transport Protocol Network Job Entry (SMTPD NJE) Mail Gateway and Sendmail mail transports are planned to be removed from z/OS. IBM now plans for z/OS V2.2 to be the last release to include these functions. If you use the SMTPD NJE Gateway to send mail, IBM recommends you use the existing CSSMTP SMTP NJE Mail Gateway instead. In that same announcement, IBM announced plans to provide a replacement program for the Sendmail client that would not require programming changes. Those plans have changed, and IBM now plans to provide a compatible subset of functions for Sendmail in the replacement program and to announce those functions in the future. Programming changes or alternative solutions to currently provided Sendmail functions might be required. No replacement function is planned in z/OS Communications Server to support using SMTPD or Sendmail as a (SMTP) server for receiving mail for delivery to local TSO/E or z/OS UNIX System Services user mailboxes, or for forwarding mail to other destinations.

§ Migration Health Checks in V2R1 and V2R2 for SMTPD and Sendmail alert users of these applications to their coming removal


Mail components supported in z/OS V2R2

z/OS Application

TSO userIMAP, POP,

(E)SMTP protocols

CSSMTP (SMTP client)

SMTPD (SMTP client and server)

MTA

JES spoolWrite to SYSOUT

z/OS UNIX shell user

z/OS Sendmail (SMTP client and server)

non-z/OS user using z/OS Sendmail as the target server

z/OS

(E)SMTP protocols

(E)SMTP protocol

SMTP protocol

(E)SMTP protocol

MTA

SMTP network

NJE network

z/OS

z/VSE

z/VM

MTAUnix FileSystem


Mail component changes in z/OS V2R3

z/OS Application

TSO userIMAP, POP,

(E)SMTP protocols


SMTPD (SMTP client and server)

MTA



z/OS Sendmail (SMTP client and server)

non-z/OS user using z/OS Sendmail as the target server

z/OS

(E)SMTP protocols

(E)SMTP protocol

SMTP protocol

(E)SMTP protocol

MTA

SMTP network

NJE network

z/OS

z/VSE

z/VM

MTAUnix FileSystem

X

X

XX

XX

X

XX

X


Mail components in z/OS V2R3

z/OS Application

TSO userIMAP, POP,

(E)SMTP protocols


MTA



z/OS sendmail to CSSMTP bridge

z/OS

(E)SMTP protocols

(E)SMTP protocol

MTA

SMTP network

NJE network

z/OS

z/VSE

z/VM

MTAUnix FileSystem

Strategic Mail Solution

Messages formatted for CSSMTP and placed into JES spool for CSSMTP to

process

Bottom line: You can still send mail from z/OS using CSSMTPD and the sendmail bridge. But you cannot receive it.


• Difficult to continue to support three mail programs• SMTPD NJE Gateway:

• Pascal API application• Supports older SMTP RFCs, no support for TLS/SSL or IPv6• Performance issues (single-threaded)

• z/OS UNIX sendmail:• Ported code version 8.12.1 (2001/10/01) – out of date

§ CSSMTP was introduced in z/OS V1R11 and has been the strategic mail program• All development/support efforts focused on CSSMTP• CSSMTP already provides superior performance, function, and currency as

compared to SMTPD and sendmail• The CSSMTP Test Mode capability and the EZBMCOPY utility program were

provided on V2R1 (via APAR) and V2R2 to assist with verifying SMTPD mail workloads in your production environment (see appendix)

Removal of SMTPD and Sendmail


§ The SMTPD NJE Gateway and z/OS UNIX sendmail are removed in z/OS V2R3• Neither SMTPD nor the sendmail daemon can be configured or

started in z/OS V2R3• No replacement function provided by z/OS Communications

Server for receiving mail for delivery to local TSO/E or z/OS UNIX System Services user mailboxes or for forwarding mail to other destinations

• While some users may be accustomed to issuing sendmailcommands from the UNIX shell, more problematic is the fact that some applications may issue sendmail commands as part of their processing- Sendmail commands can still be issued in V2R3 due to the

presence of the sendmail to CSSMTP bridge (see next chart)

Removal of SMTPD and Sendmail …


Sendmail to CSSMTP bridge

§ To allow the processing of many existing sendmail command variations, z/OS V2R3 CS provides a sendmail to CSSMTP bridge (sendmail bridge)

§ The sendmail bridge:

§ Parses input options from the command line

§ Reads mail message from UNIX System Services file

§ Mail message updated by adding SMTP commands and SMTP headers (if no header specified in input mail message)

§ Mail message transmitted to JES spool data set

§ CSSMTP processes mail messages on the JES spool data set

§ The sendmail command is now a symbolic link to the sendmail bridge, allowing applications and users to continue to issue sendmail commands


Sendmail to CSSMTP bridge …



§ The bridge may also be directly invoked by using the ezatmail command:

§ Example:

ezatmail -t </tmp/mymail2

/tmp/mymail2 contains:

From: [email protected]: [email protected], [email protected]: Good job today

Great work!



§ sendmail command is directed to the sendmail bridge (ezatmail) sendmail comand_switch(es) recipient name(s) <input mail message

Example: sendmail [email protected] </tmp/mymail1

/tmp/mymail1 contains: From: [email protected]: Good job today Great work!

Result: Message updated with SMTP commands & headers, and transmitted to JES spool data set

§ Sendmail could be invoked both from the OMVS shell and through JCL (via BPXBATCH), so the sendmail bridge is able to be invoked in the same way

§ See the appendix for more information on the sendmail bridge, including configuration statements, command line switches, and options supported


§ Support for the sendmail to CSSMTP bridge will also be provided for z/OS V2R1 and V2R2 with APAR PI71175• ezatmail command invokes sendmail bridge• sendmail unchanged• Symbolic link can be added for sendmail to invoke sendmail

bridge (ezatmail) for testing

Sendmail to CSSMTP bridge on V2R1 and V2R2


§ The CSSMTP Compatibility Enhancements are several items intended to improve the compatibility of CSSMTP with existing customer environments.• Intent is to remove remaining inhibitors to migrating from

SMTPD-based mail to CSSMTP-based mail§ The items are:

• Improved TLS compatibility with mail servers• CSSMTP customizable ATSIGN character for mail addresses• Improved CSSMTP code page compatibility with target servers

CSSMTP compatibility enhancements


§ CSSMTP reads mail jobs from JES and sends emails to a target server for delivery to destination

§ TLS security setup between a client (CSSMTP) and target server defined in RFC 3207, with an optional second EHLO and capabilities exchange after TLS negotiation• CSSMTP does not do 2nd EHLO and capabilities exchange

§ Some target servers will not connect with CSSMTP after TLS negotiation without the second EHLO and capabilities exchange

§ Mail sent by CSSMTP to some target servers cannot be secured with TLS

§ V2R3 provides a configuration option to enable an EHLO and capabilities exchange following TLS negotiation• Provides CSSMTP compatibility with target servers that require a

second EHLO and capabilities exchange

Improved TLS compatibility with mail servers


§ CSSMTP configuration file:• New parameter on the Options statement: TLSEhlo No | Yes • Example:

Options {

TLSEhlo Yes }

§ If the server requires an EHLO command to be sent after a successful TLS negotiation, set TLSEhlo to Yes• Default value is No

§ Support also provided for z/OS V2R1 and V2R2 with APAR PI56614. • APAR PI77267 is additional recommended maintenance.

Improved TLS compatibility with mail servers …


Improved TLS compatibility with mail servers …

§ The new option can be seen via the F CSSMTP,DISPLAY,CONFIG command:

F CSSMTP,DISPLAY,CONFIG EZD1829I CSSMTP CONFIGURATION:

CONFIGFILENAME : /u/user1/cssmtp/cssmtp.confnewLOGFILENAME : /u/user1/cssmtp/cssmtp.log

... OPTIONS: NULLTRNC : NO DATALINETRUNC : NO TESTMODE : NO ATSIGN : 7C TLSEHLO : NO

... TARGETSERVER: TARGETNAME : us.ibm.comCONNECTPORT : 25 CONNECTLIMIT : 5 MAXMSGSENT : 0 MESSAGESIZE : 524288 SECURE : NO CHARSET : ISO8859-1

TIMEOUT: ANYCMD : 300 CONNECTRETRY : 120 DATABLOCK : 180 DATACMD : 120 ...


§ SMTPD has limited code page support• IBM-1047 was used for EBCDIC to ASCII conversion• SMTPD had no knowledge of IBM-273 or other code pages

§ Code point for ATSIGN (@) symbol varies in code pages, for example:

§ Many customers that use IBM-273 modified mail generating programs to force x'7C' character to represent ATSIGN to overcome SMTPD's limited code page support

§ CSSMTP does translation of input mail messages through iconv• So, if the above modification is left in place, the wrong ’@’ character

will result now that CSSMTP uses the correct code page§ To migrate from SMTPD to CSSMTP, customer must update mail

generating programs

CSSMTP customizable ATSIGN character for mail addresses


§ Configuration option provided to define the ATSIGN character used by mail generating programs

§ CSSMTP processing:• Read mail data set from JES and translate it to IBM-1047• Search SMTP commands and headers for the configured

ATSIGN symbol• Update character to x'7C' (@ in IBM-1047) • Body of mail remains unchanged

§ Simplifies migration path from SMTPD to CSSMTP• no change required to mail generating programs

CSSMTP customizable ATSIGN character for mail addresses …


§ CSSMTP configuration file:• New parameter on the Options statement : AtSign character• Example:

Options {

AtSign §}

• Default is ‘@’ (hex ‘7C’)§ Support also provided for z/OS V2R1 and V2R2 with APAR

PI52704







... OPTIONS: NULLTRNC : NO DATALINETRUNC : NO TESTMODE : NO ATSIGN : 7C TLSEHLO : NO ...

TARGETSERVER: TARGETNAME : us.ibm.comCONNECTPORT : 25 CONNECTLIMIT : 5 MAXMSGSENT : 0 MESSAGESIZE : 524288 SECURE : NO CHARSET : ISO8859-1



§ CSSMTP TRANSLATE configuration statement specifies code page of the JES spool files

§ Mail message commands and headers translated from configured TRANSLATE code page to IBM-1047 EBCDIC for processing, then translated to ISO8859-1 ASCII before sending to target server

§ Body of mail message directly translated to ISO8859-1 ASCII before sending to target server

§ No option to configure the ASCII code page for the target server§ The euro sign (€) is not included in ISO8859-1 or IBM-1047§ ISO8859-1 not always compatible with target server code page

Improved CSSMTP code page compatibility with target servers


§ Configuration parameter, Charset, provided to specify code page to be used when translating mail message to be sent to target server

§ Mail message body translated from the TRANSLATE code page directly to configured Charset code page

§ Mail message headers translated from IBM-1047 code page to Charset code page

§ Charset code page must be defined to Unicode System Services§ Improves CSSMTP code page compatibility with target servers§ CSSMTP can be configured to use same code page as target

server• Characters, such as the euro sign (€), are supported in body of

mail message

Improved CSSMTP code page compatibility with target servers …


§ CSSMTP configuration file• New parameter on the TargetServer statement : Charset

codepage- Defines the code page that the target server expects to be

used for mail messages• Example:

TargetServer{

. . . Charset 1252

}

• Default value is ISO8859-1§ Support will also be provided for z/OS V2R1 and V2R2 with APAR

PI73909







... OPTIONS: NULLTRNC : NO DATALINETRUNC : NO TESTMODE : NO ATSIGN : 7C TLSEHLO : NO ...

TARGETSERVER: TARGETNAME : us.ibm.comCONNECTPORT : 25 CONNECTLIMIT : 5 MAXMSGSENT : 0 MESSAGESIZE : 524288 SECURE : NO CHARSET : ISO8859-1



Wildcard Support for

Jobnames on PORT &

PORTRANGE Statements


• The PORT and PORTRANGE configuration statements allow a user to restrict which programs can bind or listen to a particular port• The PORT statement is used to restrict a single port• The PORTRANGE statement is used to restrict multiple ports

• The JOBNAME parameter on the PORT and PORTRANGE statements specify which jobs are authorized to bind or listen to a port

• A wildcard character of asterisk can be used to specify which jobs can bind or listen to a port• An asterisk by itself can be used to mean match on any job

name• An asterisk is allowed at the end of a partial job name

§ Customers have requested more flexible wildcard support to avoid having to code extra PORT/PORTRANGE statements

Jobnames on PORT and PORTRANGE statements


• The PORT/PORTRANGE statements are changed to support:• Asterisks in any position

- Asterisk represents zero or more unspecified characters• Question marks in any position

- Question mark represents a single unspecified character§ It is possible for multiple PORT/PORTRANGE statements to match a job

name. In that case, these rules determine the best match:• The job name is compared character by character from left to right

- When a character in the job name does not match the specification, the following hierarchy is used to determine which is the best match:– A non-wildcard character takes precedence over a wildcard

specification– A single wildcard character of question mark takes precedence

over the multiple wildcard character of asterisk

Enhanced wildcard support for Jobnames on PORT and PORTRANGE statements


• Example 1:

PORT 6001 TCP JOBNAME US?R*PORT 6002 TCP JOBNAME US*R*

• A job with name USER15 binds to port 6001• The JOBNAME of US?R* would match.

- Single wildcard of '?' beats multiple wildcard of '*’

• Example 2:

PORT 6001 TCP JOBNAME U?ER*PORT 6002 TCP JOBNAME US*R*

• A job with name USER15 binds to port 6002• The JOBNAME of US*R* would match.

- Specific match on 'S' beats '?'

Enhanced wildcard support examples


AT-TLS Currency

with System SSL


Application Transparent Transport Layer Security (AT-TLS)

§ Stack-based TLS• TLS process performed in TCP layer (via

System SSL) without requiring any application change (transparent)

• AT-TLS policy specifies which TCP traffic is to be TLS protected based on a variety of criteria

§ Application transparency• Can be fully transparent to application• An optional API allows applications to inspect or

control certain aspects of AT-TLS processing –“application-aware” and “application-controlled” AT-TLS, respectively

§ Uses System SSL for TLS protocol processing• Remote endpoint sees an RFC-compliant

implementation• Interoperates with other compliant

implementations

encr

ypte

d NetworkingIPv4, IPv6

DLC

Transport (TCP)

Sockets API

TCP/IP Application

AT-TLS

z/O

S C

S Po

licy

infr

astr

uctu

re

AT-TLSpolicy

AT-TLS policy administratorusing Configuration Assistant

System SSL


• Since z/OS CS handles the TLS processing transparently for exploiting applications, it is necessary for AT-TLS to support enhancements made by System SSL. This will usually include:• Externalizing new options and parameters through policy

definitions• Updating the Configuration Assistant to support those new

parameters and options§ And may include:

• Updates to netstat and/or pasearch commands• Updates to IPCS formatters• Updates to NMIs, SMF records, or IOCTLs

AT-TLS currency with System SSL


• Provide FIPS 140-2 security levels to enforce different cryptographic strengths (NIST SP800-131A Revision 1)

• Support new certificate processing controls defined in NIST SP800-52A Revision 1

• Support new OCSP features, such as OCSP stapling (RFC 6066, 6277, 6960, 6961) • OCSP stapling supports the inclusion of the OCSP response for

the server's certificate as a TLS extension during the TLS handshake

§ Support new 128Min and 192Min profiles for the Suite B Profile (RFCs 6460 and 5759)

§ Support the Signaling Cipher Suite Value (SCSV) which can provide protection against protocol downgrade attacks (RFC 7507)• Allows the server to detect and avoid an inappropriate fallback to

an earlier protocol version during the handshake

AT-TLS currency with System SSL …


Miscellaneous

V2R3 Topics


• z/OS V2R2 added enhanced system symbol support:• Longer system symbol names (up to 16 characters) and longer

symbol substitution values- Note that the length of symbol substitution values should not

exceed the length of the symbol names• Underscore added as a valid character in a system symbol name

- z/OS V2R2 CS did not support a system symbol with an underscore in a TCP/IP profile configuration file

- z/OS V2R2 CS did not support longer symbol substitution values in some cases

§ z/OS V2R3 CS adds support for a system symbol with an underscore character, and support for longer symbol substitution values

Support for enhanced system symbols


Background: getaddrinfo() is an API that allows socket applications to resolve hostnames to IP addresses

• Supports both IPv4 and IPv6 address lookups• Very flexible API that provides many options to customize the results of the

lookup• Ability to request IPv4 only, IPv6 only, or both IPv4 and IPv6• Supported on z/OS since z/OS V1R4 when IPv6 support was introduced on

z/OS- Initially designed using a late level draft of RFC2553- After z/OS introduced this new API in z/OS V1R4, a later level of RFC

2553 was defined, and subsequent to that, RFC 3493 was created which made RFC 2553 obsolete

- While the z/OS implementation is compliant to the standards for most use cases, there is one very specific scenario where non-compliance has been detected

– As a result, some IPv6 enabled applications being ported to the platform have required some minor changes

IPv6 getaddrinfo() API standards compliance


• Specific scenario of concern – getaddrinfo() invoked with the following options and configuration:

• AF_UNSPEC is specified as the ai_family• AI_ALL flag is not specified• IPv6 is enabled on the z/OS system• IPv6 addresses are defined for the hostname

§ Prior to V2R3, this would have resulted in only IPv6 addresses being returned on the query

§ Beginning with z/OS V2R3, the getaddrinfo API returns all IPv4 and IPv6 addresses that are associated with the hostname when the above settings are true.

§ This will make the API consistent with the specifications and make the processing consistent with the existing (pre-V2R3) behavior of the API when invoked on a system that does not have IPv6 enabled.

• Provides getaddrinfo compliance with RFC 3493 and the Single UNIX Specification v3 (SUSv3)• Eliminate a migration consideration when porting applications to z/OS.

§ Do not expect many applications to be impacted• Applications following the suggested IPv6 enablement for getaddrinfo() should not be impacted

- More information on gettaddrinfo can be found in the “Protocol-independent nodename and service name translation” section of the z/OS Communications Server: IPv6 Network and Application Design Guide.

IPv6 getaddrinfo() API standards compliance …


Sysplex-wide security associations (SWSA)

APP

APPSysplexDistributor

WLM

SysplexDistributor

Hot Standby

VIPA1

HiddenVIPA1

HiddenVIPA1

z/OS SysplexPagent

Inbound data path

Outbound data path

• Sysplex-wide security associations (SWSA) combine sysplex distributor technology with IPSectechnology

• Sysplex distributor negotiates security associations (SAs) with remote clients using the Internet Key Exchange protocol (IKE)

• Copies of SAs (shadows) to are sent to target stacks

• Target stacks use the SAs to encrypt and decrypt data

• Backups can recover SAs in case of planned or unplanned DVIPA takeover• Information about SAs is maintained in the EZBDVIPA coupling facility structure

• Used for DVIPA takeover and sysplex distribution• In V2R2 and earlier, the number of available lists is fixed at 2048.

• Number of lists actually utilized is determined by the number of DVIPAs and the number of security associations (tunnels)


• In V2R2, the maximum number of DVIPAs for a single stack was increased from 1024 to 4096

• In V2R2, the IKE daemon was redesigned to make heavy use of multithreading in order to increase its scalability

• These scalability improvements, along with the growing adoption of IPSec, increases the likelihood that a customer will encounter the current maximum of 2048 lists in EZBDVIPA

Sysplex-wide security associations (SWSA) scalability improvement


• V2R3 adds a new VTAM start option, DVLSTCNT, that specifies the number of lists that the EZBDVIPA structure(s) can have• DVLSTCNT can be set to one of four possible values: 2048

(default), 4096, 8192, or 16384• The same value should be specified on all z/OS systems in the

sysplex• All systems must be at V2R3• DVLSTCNT is changeable by the Modify VTAMOPTS command

• The CFSIZER tool has been updated to provide guidance in choosing the value for DVLSTCNT

Sysplex-wide security associations (SWSA) scalability improvement …


Summary of z/OS CS TCP/IP device drivers – V2R1 and priorDevice driver type Supported

SMC-R and SMC-D yes

OSA Express QDIO (OSD, OSX) yes

Hipersockets (iQDIO) yes

Legacy OSA (LCS – OSE) yes

CTC P2P yes

MPC P2P (Multi-path Channel Point-to-Point) yes

XCF (Dynamic XCF) yes

MPC SAMEHOST yes

SNALINK (LU0 and LU6.2) yes

X.25 SAMEHOST yes

CLAW (e.g. Cisco CIPs) yes

Hyperchannel yes

CDLC (3745/3746 connections) yes

ATM yes

FDDI and Token Ring (LCS with LINKs FDDI/IBMTR) yes

Token Ring (MPCIPA with LINK IPAQTR) yes

ENet and FDDI (MPCOSA with LINKs OSANET/OSAFDDI) yes


Summary of z/OS CS TCP/IP device drivers – V2R2Device driver type Supported

SMC-R and SMC-D yes




CTC P2P yes



MPC SAMEHOST yes

SNALINK (LU0 and LU6.2) No - Removed in V2R2

X.25 SAMEHOST No - Removed in V2R2

CLAW (e.g. Cisco CIPs) No - Removed in V2R2

Hyperchannel No - Removed in V2R2

CDLC (3745/3746 connections) No - Removed in V2R2

ATM No - Removed in V2R2

FDDI and Token Ring (LCS with LINKs FDDI/IBMTR) yes

Token Ring (MPCIPA with LINK IPAQTR) yes

ENet and FDDI (MPCOSA with LINKs OSANET/OSAFDDI) yes


Statement of Direction: End of support for additional TCP/IP legacy device drivers (Issued July 28, 2015)

z/OS V2.2 is planned to be the last release to include the TCP/IP legacy device drivers for FDDI and Token Ring (LCS with LINKs FDDI and IBMTR), Token Ring (MPCIPA with LINK IPAQTR), and ENet and FDDI (MPCOSA with LINKs OSAENET and OSAFDDI). If you are using any of these devices, IBM recommends you migrate to newer devices such as OSA Express QDIO and Hipersockets. Note that this withdrawal is only for TCP/IP device types, and not for any of the SNA device drivers.


Summary of z/OS CS TCP/IP device drivers – V2R3Device driver type Supported

SMC-R and SMC-D yes




CTC P2P yes



MPC SAMEHOST yes

SNALINK (LU0 and LU6.2) No - Removed in V2R2

X.25 SAMEHOST No - Removed in V2R2

CLAW (e.g. Cisco CIPs) No - Removed in V2R2

Hyperchannel No - Removed in V2R2

CDLC (3745/3746 connections) No - Removed in V2R2

ATM No - Removed in V2R2

FDDI and Token Ring (LCS with LINKs FDDI/IBMTR) No – Removed in V2R3

Token Ring (MPCIPA with LINK IPAQTR) No – Removed in V2R3

ENet and FDDI (MPCOSA with LINKs OSANET/OSAFDDI) No – Removed in V2R3


Statement of Direction: Trivial File Transfer Daemon (TFTPD) (Issued July 28, 2015)

z/OS V2.2 is planned to be the last release to include the Trivial File Transfer Protocol Daemon (TFTPD) function in z/OS Communications Server.

• TFTPD has been removed from z/OS Communications Server in V2R3


Configuration Assistant

Updates


Configuration Assistant: TCP/IP stack configuration

§ Skilled z/OS system programmers and administrators are an aging skillset, leading to concerns about future skill shortages.

§ Configuration Assistant (CA) only supports configuration of z/OS CS policy-based networking functions, such as IPSec, AT-TLS, and IDS.

§ While TCP/IP configuration is not that complex, some aspects are not intuitive.

§ User must look through a lot of documentation.§ Some statements are not easy to configure. V2R1 Configuration Assistant:

Interface for Communications Server policy based definition,

installation and activation

z/OSWebSphere Application Server

z/OSMF


Configuration Assistant: TCP/IP stack configuration …

§ V2R2 provides a new “TCP/IP” configuration perspective in the CA

§ Support is provided for both novice and more experienced users.

§ The configuration model supports “levels of configuration” which include a sysplex level, image level, and a stack level with the goal to allow for configuration to be applied for grouping of stacks that require related configuration.

§ CA assists with “install” of the generated configuration files as it does with policy configuration.


Statement of Direction: Configuration Assistant for z/OS Communications Server (Issued July 28, 2015)

IBM plans to further extend the capabilities of the Configuration Assistant for z/OS Communications Server, a plug-in for z/OSMF, in z/OS V2.2. Additional planned enhancements will be designed to support making dynamic configuration changes to an active TCP/IP configuration, and a function designed to import existing TCP/IP profile data.

The function to import existing TCP/IP profile data shipped on 9/1/16 in two APARs:• Configuration Assistant: PI66143/UI40466• Communication Server: PI63449/UI40186


Statement of Direction: Configuration Assistant for z/OS Communications Server (Issued July 28, 2015)

IBM plans to further extend the capabilities of the Configuration Assistant for z/OS Communications Server, a plug-in for z/OSMF, in z/OS V2.2. Additional planned enhancements will be designed to support making dynamic configuration changes to an active TCP/IP configuration, and a function designed to import existing TCP/IP profile data.

As stated in the preview announcement for zOS V2R3, we plan to provide in V2R3 the support in Configuration Assistant for the ability to change an active TCP/IP stack configuration by generating the required VARY OBEY member.


Full VTAM Internal

Trace (VIT)

Control


VTAM Internal Trace – Disabling SMS VIT option

§ There are eight VIT options that are enabled by default• API,CIO,MSG,NRM,PIU,PSS,SMS,SSCP

§ Given the infrequent need for the SMS option during problem diagnosis, it is often not worth the CPU cost of the SMS option for the slight improvement in first failure data capture.

§ Therefore, we believe that disabling the SMS VIT option is the best choice for most customers except those actively working to gather problem documentation under the direction of IBM Level 2 support.

§ APAR OA49999 changed the default option set to no longer include SMS• Available on V2R1 and V2R2• Base behavior in V2R3


Improved control over default VTAM VIT options

§ APAR OA50271 is a new function APAR that allows the full capability of controlling (including disabling) all VIT options• APAR is available on V2R1 and V2R2 • Base behavior in V2R3

§ This support does not change the IBM minimum-recommended set of VIT options• API, PIU, SSCP, NRM, MSG, CIO, PSS – existing VIT options group STDOPTS• Disabling any or all of these options will impact IBM Level 2 support’s ability to

diagnose problems- More likely to need to ask for a recreate

§ This new VIT operator control capability is enabled with a new VTAM start option called VITCTRL (VTAM Internal Trace Control) that by default preserves the existing behavior, but allows the user to enable the new behavior (full control of the VIT options).


Improved control over default VTAM VIT options …

§ VITCTRL supports two modes:• BASE: Preserves the existing support. This is the default.• FULL: New mode allowing the operator to fully control all VIT options using the existing

MODIFY TRACE and NOTRACE commands§ VITCTRL only applies to MODE=INTERNAL VITs. It has no impact on external

VITs.§ The health check CSVTAM_VIT_OPT_STDOPTS will detect if any options within

STDOPTS have been disabled


Thank you!


Additional Details on

z/OS V2R3 CS Content

and Other Topics


Additional Details on

CSSMTP to

Sendmail Bridge


Sendmail to CSSMTP bridge: Functions supported§ The sendmail bridge is a limited function replacement for the full sendmail program.

It does not support everything that sendmail supports. When it does support a function that sendmail supports, the configuration or invocation of that function is compatible with the sendmail command.

§ Configuration statements supported for the sendmail bridge:

Configuration Statement

Description Note(s)

# CommentsD Define macro definition See "Macro definitions supported"

O Define an option See ”Options supported"

W Define the CSSMTP writer name Search order for determining the CSSMTP external writer name : • The -W command switch• The EZATMAIL_CSSMTP_EXTWRTNAME

environment variable is used • The W statement is specified in the

configuration file• Defaults to CSSMTP


Sendmail to CSSMTP bridge: Command line switches supported§ The sendmail bridge command can only be invoked from z/OS UNIX Shell

command or by submitting a batch job that invokes BPXBATCH Switch Description Note(s)

-bM Set operating role to be a mail sender (client role)

-bm (Mail sender) is the only value supported

-C Location of the configuration file

-dcategory.level Debugging mode

-F Set sender’s full name (only one name)

-f Set sender’s address (only one address)

-n Don’t do aliasing See “alias support”-O Set a multi-character option See “Options supported”

-t Get recipients from message header

-v Run in verbose mode Logs the content of the built JES spool data set

-Wextwtr Define CSSMTP external writer name Option to provide the CSSMTP external writer name. The default is CSSMTP.


Sendmail to CSSMTP bridge: Macro definitions supported§ The following sendmail macro definitions are supported

Macro definition

Description Example(s)

Dj hostname.domain_name Dj$w.$m Dj$w.DOMAIN.IBMDjMVSTST1.DOMAIN.IBM

Dm domain name DmDOMAIN.IBM

Dw short hostname DwMVSTST1

D{tls_version} If defined, then STARTTLS SMTP command is generated, otherwise only EHLO is generated.

D{tls_version}=tlsv1


Sendmail to CSSMTP bridge: Options supported§ The following options are supported by the sendmail bridge

§ For information on supported command line switches, macro definitions, and options, see “Sending emails by using the sendmail to CSSMTP bridge” in z/OS Communications Server: IP User's Guide and Commands

Option Example DescriptionAliasFile O AliasFile=/u/user1/alias.txt

-OAliasFile=/u/user1/alias.txtDefine the full alias file name path

MaxAliasRecursion O MaxAliasRecursion=n-OMaxAliasRecursion=n

Define the maximum recursive depth when resolving aliases

MaxRecipientsPerMessage O MaxRecipientsPerMessage=n-OMaxRecipientsPerMessage=n

Range 0-2000. Sets the maximum number of recipients per email message


Sendmail to CSSMTP bridge: Alias support

§ Notes on alias support

§ Will support mail addresses or other alias

§ Will support mailing lists with :include

§ Will not support delivery of a message by appending to a file (/file)

§ Will not support delivery by piping the message through a program (|program)

§ Will not support rebuild of alias database

/u/user1/alias.txt contains: cssmtp: sue1, sue2 mike: [email protected]: [email protected]: [email protected]: [email protected]: :include:/u/user1/maillist

/u/user1/maillist contains:[email protected]@[email protected]


CSSMTP Test

Mode Support and

EZBMCOPY


• CSSMTP has stricter standards than SMTP• How do you verify that CSSMTP will process your existing production

mail workload?• V2R2 function: CSSMTP test mode

• A new configuration parameter that causes CSSMTP to run in Test Mode- CSSMTP will perform its normal email processing, except it will not

actually send emails- It will report email failures and discard successful emails- You can address incompatible emails before migrating to CSSMTP

• SMTPD continues to process your mail messages- Production emails are unaffected during the test

• EZBMCOPY- Utility program provided by IBM to copy JES email messages to two

destinations, SMTPD and CSSMTP•This is available on V2R1 via APAR PI48700

Mail migration strategy: SMTPD to CSSMTP


TEST Mode/EZBMCOPY architecture


CSSMTP Test Mode

• Notes on TestMode:• TestMode cannot be dynamically altered. CSSMTP must be recycled

to change its value • If no errors are found in a spool file, CSSMTP will release spool files

when it has completed processing. If errors are found, CSSMTP will honor the setting of BADSPOOLDISP

• Make sure the REPORT statement is coded with a valid destination for the error report. Warning message EZD1841I is issued if it is not.

• Parameters on the CSSMTP Options statement:

>>--Options-----| Put Braces and Parameters on Separate Lines |--><

Options Parameters:

+--TestMode NO------+

|----+-------------------+----->

+--TestMode-+-NO--+-+

+-YES-+


CSSMTP display config

The new configuration parameter is also externalized using the CSSMTP SMF configuration record (CONFIG subtype 48)

F CSSMTP,DISPLAY,CONFIGEZD1829I CSSMTP CONFIGURATION:CONFIGFILENAME : /U/USER1/CSSMTP/CSSMTP.CONF

[…]

BADSPOOLDISP : HOLD REPORT : SYSOUTOPTIONS:NULLTRUNC : NO DATALINETRUNC : NOTESTMODE: : NO

[…]


• Parm value:• WRITER=w Select program name (writer name) w

• EZBMCOPY assumes the writer name specified by the WRITER parameter. It selects spool files in two ways:

• The file's writer name matches the WRITER parameter, or• The file's destination matches the WRITER parameter

• Then it makes as many copies as there are OUTPUT cards in the JCL, then deallocates the original data set

• Restriction: a maximum of two output cards can be coded

EZBMCOPY


EZBMCOPY usage example

• Assume the JCL shown here and SMTPD running with writer name SMTPD. (note: SMTPD's writer name is its jobname)

•Change the writer name of SMTPD to SMTPD1 for this test by changing its jobname to SMTPD1•Start CSSMTP in TESTMODE with writer name CSSMTP•Start EZBMCOPY using the example JCL above

//EZBMCOPY PROC //STEP EXEC PGM=EZBMCOPY,PARM='WRITER=SMTPD'//OUT1 OUTPUT WRITER=SMTPD1 //OUT2 OUTPUT WRITER=CSSMTP //STEPLIB DD DSN=JES2.TESTING.LOAD,DISP=SHR//SYSUT2 DD SYSOUT=*,SPIN=UNALLOC,OUTPUT=(*.OUT1,*.OUT2) //SYSPRINT DD SYSOUT=* //SYSIN DD DUMMY

z/os v2r3 communications server content preview

Software