How does zERT discovery provide the information?

As cryptographic protection attributes for TCP and Enterprise Extender connections are discovered and collected, you can direct zERT to write those attributes, along with relevant connection information, to the z/OS® System Management Facility, to a network management application using the real-time NMI for zERT information, or to both. Regardless of the destination, the information is recorded using SMF 119 subtype 11 (zERT connection detail) records.

zERT connection detail records have the following general format:

Figure 1. zERT connection detail (SMF 119 subtype 11) record layout
zERT connection detail (SMF 119 subtype 11) record layout

One or more zERT connection detail records are generated for each TCP and Enterprise Extender connection. The zERT Connection Common Section contains an event type field that indicates the reason each subtype 11 record is generated. The number of subtype 11 records written for a given connection depends on a couple of different factors:

  • For TCP connections, the length of time that the connection exists can influence the number of records written.
    • TCP connections that last 10 seconds or longer will generate an SMF 119 subtype 11 record after the connection has existed for 10 seconds, and this is called a Connection Initiation event; when the TCP connection terminates, it will generate another record, and this is called a Connection Termination event.
    • TCP connections that last less than 10 seconds and do not experience a significant change in cryptographic protection during that time generate a single subtype 11 record when the TCP connection terminates. This is called a Short Connection Termination event.
  • Start of changeFor EE connections, both a Connection Initiation and a Connection Termination event are generated.End of change
  • Any time there is a significant change in the cryptographic protection state after the initial cryptographic state is established, a subtype 11 record will be written to record the new state. This is called a Protection State Change event.
  • Start of changeIf a TCP connection matches a zERT enforcement rule that requested an audit record, a subtype 11 record will be written. This is called a zERT Enforcement event.
    Restriction: zERT enforcement policy rules are not supported for EE connections.
    End of change

Each connection-specific subtype 11 record contains information about the connection itself in the zERT Start of changeConnection Common SectionEnd of change. This includes information like the local and remote connection endpoints, the attributes of the owner of the local socket such as userid and jobname, and information about which cryptographic protocols, if any, are being used to protect the connection.

For connections that have recognized TLS, SSL, SSH or IPSec attributes, the record contains a protocol-specific section that contains important cryptographic attributes of the security session that is protecting the connection. This includes the following attributes:
  • Peer authentication method
  • Cryptographic algorithms and key lengths in use for encryption, message authentication and key exchange
  • Additional useful information like security session lifetime and X.509 certificate serial numbers

Start of changeFor connections protected by a security protocol that is using X.509 certificates for peer authentication, an X.509 Distinguished Name (DN) section is included with subject and issuer DNs from the end-entity certificates used for the connections.End of change

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

Start of changeFor TCP connections that map to at least one zERT enforcement rule, the subtype 11 record contains a zERT policy-based enforcement section with the rules to which it was mapped.End of change

Finally, if the connection is subject to an IP filter rule, the subtype 11 record also contains information about the inbound and outbound rules that are controlling the flow of traffic over the connection.

  1. Since Enterprise Extender (EE) traffic flows over UDP, the only cryptographic protocol that is capable of protecting this traffic is IPSec. As such you may see subtype 11 records for EE connections that have no recognized cryptographic protection, or that are protected by IPSec. In the IPSec case, each subtype 11 record will contain an IP filtering section and an IPSec section. In the case of no recognized protection, the subtype 11 records will have no protocol-specific section and may or may not have an IP filtering section, depending on the local IP filtering policy.
  2. Since TCP traffic may be protected by not only IPSec, but also by TLS/SSL and SSH, subtype 11 records may have zero or more protocol-specific sections as described above. They may also have IP filtering sections in the same manner as Enterprise Extender traffic.

Subtype 11 records are also written in two special cases: when zERT discovery is enabled or disabled through the GLOBALCONFIG parameter.

For more information on the SMF 119 zERT connection detail (subtype 11) records, see zERT connection detail record (subtype 11) in z/OS Communications Server: IP Programmer's Guide and Reference.