Securing LU-LU Sessions Part 2

Implementing Security for APPC z/OS › Implementing APPC Security › Securing LU-LU Sessions Part 2 - APPCLU

Securing LU-LU Sessions Part 2 - APPCLU

After reviewing your security requirements and determining which LUs will be used for APPC conversations and what level of security should be maintained for those conversations, you need to identify authorized LU links to CA Top Secret. The LINKID keyword is used to identify the authorized LU links.

The APPCLU record maintains a list of LINKIDs (one LINKID per LU‑LU connection) in the following format:

netid.localLU.partnerLU

netid

The name of the network on which the local LU resides.

Note: You should supply the same netid specified by the netid= statement in the VTAM ATCSTRxx member.

localLU

The VTAM name of the local LU.

partnerLU

The VTAM name of the partner LU.

You do not have to specify all three values. However, the algorithm is designed to search for the best match. Therefore the most explicit entry (i.e., the longest) which best matches the requested resource name will be used. The following entries begin with the most explicit example and end with the least explicit example.

NET1.SYSTEMA.SYSTEMB
NET1.SYS
NET

LINKID and APPCLU

To add an entry to the APPCLU record, use the following syntax:

TSS ADDTO(APPCLU) LINKID(netid.localLU.partnerLU)
    [SESSKEY(sesskey) INTERVAL(nnnnn) [CONVSEC(operand)]]

    ‑ or ‑
    [SESSLOCK]

Note: If you have the network qualified names feature active in VTAM, use the four-level name or a prefix. For example:

local-netid.luid1.remote-netid.luid2.

If you do not have the network qualified names feature active in VTAM, use the three-level name. For example:

netid.localLU.remoteLU.

These entries can later be REMOVEd through the TSS REMOVE command and updated using the TSS REPLACE command.

LINKID Keywords

The LINKID keyword is used to maintain the appropriate entry to the APPCLU record for APPC conversations. Each LINKID entry can be associated with one or more of the following keywords:

SESSKEY

A 16‑byte hexadecimal encryption key unique to each LU‑LU authorized link. If additional verification is required for a session to be established between the two LUs, the SESSKEY is used to encrypt and decrypt connection messages. If the exchange is satisfactory to both LUs, the session is established.

Note: If you supply a SESSKEY, you must also indicate an INTERVAL.

SESSLOCK

Used to single out which LUs cannot establish sessions.

INTERVAL

Must be supplied if you indicate a SESSKEY. This keyword determines how frequently SESSKEY must be updated. The value can range from 0 to 32767 where 0 indicates that the SESSKEY does not expire.

CONVSEC

Determines what, if any, additional identification needs to be provided and verified for an LU‑LU session to be established. Select one of these values:

NONE-No security information is required.
CONV-Security information is required. A userid and password need to be verified.
Note: CONV overrides the SECACPT value specified in the VTAM APPL statement.
ALREADYV-Indicates that a userid and password have already been verified by the partner LU and that the path is trusted.
PERSISTV-Indicates that a userid and password must be verified on the first request; for subsequent requests only the userid is verified.
AVPV-Supports both ALREADYV and PERSISTV values; the security type used depends on the incoming request.

Note: CONVSEC security does not apply if you are using a VTAM release prior to 3.4.

Examples

In the following examples LSCA01 is responsible for maintaining the APPCLU record.

In this example, LU01 and LU02 can establish sessions but the SESSKEY, which is A1B2C3D4, must be verified first. That SESSKEY must also be updated every 45 days. To accomplish this, LSCA01 enters:

TSS ADDTO(APPCLU) LINKID(SYS1.LU01.LU02)
                  SESSKEY(A1B2C3D4)
                  CONVSEC(CONV)
                  INTERVAL(45)

In this example, LU01 cannot establish a session with LU03. To prevent this, LSCA01 enters:

TSS ADDTO(APPCLU) LINKID(SYS1.LU01.LU03)
                  SESSLOCK

In this example, the SESSKEY used to verify that LU02 and LU03 can establish sessions has to be updated every 30 days. Previously, the SESSKEY only had to be changed every 60 days. To institute this change, LSCA01 enters:

TSS REPLACE(APPCLU) LINKID(SYS1.LU02.LU03) INTERVAL(30)

In this example, LSCA01 can issue a TSS LIST command to review and verify the changes he has made:

TSS LIST(APPCLU) DATA(SESSKEY)

The following information is provided:

 ACCESORID   = *APPCLU*   NAME         = APPC/MVS LU SECURITY
 LINKID      = SYS1.LU01.LU02
   TOT VIOS  =     0      MAX VIOS     =     0  LINK STATUS=AVAILABLE
   CONVSEC   = CONV       VIOLATIONS   =     0
   SESS KEY  = ABCDEFGH
     EXPIRES = 92‑30‑11   INTERVAL     =    45
 LINKID      = SYS1.LU01.LU03
   TOT VIOS  =     0      MAX VIOS     =     0  LINK STATUS=UNAVAILABLE
   CONVSEC   = N/A        VIOLATIONS   =     0
   SESS KEY  = N/A
     EXPIRES = N/A

This example views a single entry in the APPCLU record:

TSS LIST(APPCLU) LINKID(SYS1.LU02.LU03)

When only a single entry is listed, the SESSKEY is not displayed. To view the SESSKEY associated with a particular LINKID, you must view the entire APPCLU record using the syntax demonstrated in the previous example.

Authority

To maintain the APPCLU record, the security administrator needs to have MISC2(APPCLU) authority. To view SESSKEYS, he must also have DATA(SESSKEY) authority.