z/OS Communications Server: SNA Network Implementation Guide
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Establishing cryptographic sessions

z/OS Communications Server: SNA Network Implementation Guide
SC27-3672-01

Cryptographic LU-LU sessions are established based on the requirements and capabilities of the session partners.

As shown in Figure 1, the application programs can establish the following sessions with the peripheral node LUs:
APPL1A
Can establish a nonencrypted session with LU1A.

Can establish a cryptographic session with LU1B if a cryptographic product is currently available. If it is not available, a session without encryption is started.

APPL1B
Can establish a cryptographic session with LU1B if a cryptographic product is currently available; otherwise the session fails.

Cannot establish a session with LU1A; the session fails. APPL1B requires a cryptographic session that LU1A does not support.

Figure 1. Encryption facility specifications
Encryption facility specifications

The MODIFY ENCR or MODIFY SECURITY can be used to change the cryptographic capability of a logical unit, or change the capability to a higher level of cryptography than was previously specified. Only MODIFY SECURITY can be used to change the minimum encryption type (ENCRTYPE).

When VTAM® tracing is in effect for a cryptographic session, the protected data in the VTAM buffers is neither displayed nor printed.

When sessions require encryption, a session could fail if a cryptographic support is not currently available. You can define some sessions to establish a clear session if cryptographic services are not available at session start. The ENCR=COND operand on the APPL definition statement specifies whether to establish a clear session if a cryptographic facility is not available. A clear session is established when a cryptographic facility is not available and one of the following conditions exist:
  • Both session partners have ENCR=COND coded.
  • When ENCR=COND is coded by one session partner and ENCR=OPT is coded for the other session partner.
If either end of a session specifies a higher level of encryption than ENCR=COND (ENCR=SEL or ENCR=REQ), an encrypted session is required and the session request fails. The following table shows examples of the interactions of the ENCR and ENCRTYPE keywords in determining the encryption level.
Table 1. DES-TDES24 encryption options
ENCR ENCRTYPE Results
SLU PLU SLU PLU
REQD REQD DES DES 8-byte DES encryption is used.
REQD REQD TDES24 DES TDES24 encryption is used if PLU hardware is capable of supporting triple-DES. The PLU side can be upgraded to triple-DES. Encryption fails if PLU hardware is not capable of supporting triple-DES.
REQD REQD DES TDES24 Encryption fails; the SLU has obtained too small a key (8 bytes) while the PLU requires a 24-byte key. The SLU VTAM cannot be upgraded; it obtains the session key.
OPT/REQD REQD DES* TDES24 (* — SLU also sets &ENCRTYP=TDES24) TDES24 encryption used, assuming both SLU and PLU hardware is capable of supporting triple-DES.
OPT COND DES TDES24 Session established in the clear. The ENCRTYPE mismatch cannot be resolved, but encryption is not required.

Information needed to encipher and decipher session information is included in session establishment commands. When a session that will use cryptography is being initiated, the cryptographic facility of the SLU SSCP/CP enciphers the cryptography key. From the cryptography key two enciphered keys are created:

  1. One copy is enciphered under the SLU master key

    The enciphered session key is placed in the BIND image to be used later. For 24–byte keys, the extra 16 bytes are transported as control vector data and not in the BIND image itself.

  2. Another copy is enciphered under a cross key.

    The enciphered cross key is inserted in the CDINIT or CDCINIT command (or corresponding APPN command) and is used by nodes along the session path. Depending on the configuration, this key is deciphered and reenciphered at every node along the session path or only by the session endpoint.

See Cryptographic keys for a description of a cross key and how these keys are entered into the various cryptographic products.

Note: The actual session data that is enciphered under the session key is enciphered and deciphered only at the session endpoints.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014