Using PassTickets

After logon, PassTickets are used to establish thread security within the RSE server. This feature cannot be disabled. PassTickets are system generated passwords with a lifespan of about 10 minutes. The generated PassTickets are based upon the DES encryption algorithm, the user ID, the application ID, a time and date stamp, and a secret key. This secret key is a 64 bit number (16 hex characters) that must be defined to your security software. For additional security, z/OS® security software handles PassTickets by default as single-use passwords.

To help understand the PassTicket usage, a brief description of RSE's security process follows:
  1. The client connects to host port 4035, RSE daemon.
  2. The RSE daemon authenticates the client, using the credentials presented by the client.
  3. The RSE daemon creates a unique client ID (security token) and an RSE server thread.
  4. The RSE server generates a PassTicket and creates a security environment for the client, using the PassTicket as password.
  5. The client connects to the host port returned by the RSE daemon.
  6. The RSE server validates the client using the client ID.
  7. The RSE server uses a newly generated PassTicket as password for all future actions requiring a password.

The actual password of the client is no longer needed after initial authentication because SAF-compliant security products can evaluate both PassTickets and regular passwords. RSE server generates and uses a PassTicket each time a password is required, resulting in a (temporary) valid password for the client.

Using PassTickets allows RSE to set up a user-specific security environment at will, without the need of storing all user IDs and passwords in a table, which could be compromised. It also allows for client authentication methods that do not use reusable passwords, such as X.509 certificates.

Security profiles in the APPL and PTKTDATA classes are required to be able to use PassTickets. These profiles are application specific and thus do not impact your current system setup.

PassTickets being application specific implies that both RSE and JES Job Monitor must use the same application ID (APPLID). By default both servers use FEKAPPL as APPLID, but this can be changed by the APPLID directive in rse.env for RSE and in FEJJCNFG for JES Job Monitor.

You should not use OMVSAPPL as application ID, because it will open the secret key to most z/OS UNIX applications. You should also not use the default MVS application ID, which is MVS followed by the system's SMF ID, because this will open the secret key to most MVS applications (including user batch jobs).

The smallest unit of a PassTicket timestamp is 1 second. This implies that all PassTickets generated within a single second by the same application for the same user ID will be identical. This, combined with z/OS security software handling PassTickets as single-use passwords, causes a problem for z/OS Explorer during logon, as multiple PassTickets will be required within a second. Therefore, z/OS Explorer requires setting a flag in the PassTicket definitions that allows the generated PassTickets to be reused.

Attention: The client connection request will fail if PassTickets are not set up correctly.