The aim of this page is to promote the RACF PassTicket concept. It was made out of personal research, excerpts of the IBM doc and of various newsgroups (mainly RACF-L, where specialists abound, to whom I am deeply indebted).
Quick link to the free offering :PTKTGEN.
A Cryptanalysis of the Passticket algorithm, discussion about an attack (updated March 1, 2003).
Security Server PDF files for z/OS V1R4.0. The PassTicket algorithm is described in "Security Server RACF, Macros and Interfaces", Chapter 11, "The RACF Secured Signon PassTicket".
An alternative to the RACF password that permits workstations and client machines to communicate with the host. It allows a user to gain access to the host system without sending the RACF password across the network.
Two additional user authentication methods could be a Kerberos implementation and the use of hashed passwords. More info on IBM's page : Security Facilities - Authenticating Users.
Yes and no. The regular RACF password is still usable. The Passticket is valid for a period of plus or minus 10 minutes (as measured on the GMT clock of the "central" system). It cannot be replayed. It is always a 8-character string (for example 4UZ5PX9A could be the value of a Passticket).
RACF PassTickets are cryptographically-generated, single-use, short-lifespan password substitutes. They are inherently more secure than passwords.
I believe it was with RACF 1.9.2 (remember restructured databases ?). Afterwards, RACF 2.2 allowed use of user IDs and group IDs in PTKTDATA profiles for better granularity of the secret keys.
But in fact it cannot !
If RACF authenticates a password field and determines that it is not the RACF password for the user ID, RACF may perform a second authentication step to determine whether the password field is a valid PassTicket (this is why you may see 2 RACF messages in the LOG if it is invalid).
A PassTicket is considered to be within the valid time range when the time of generation (with respect to the clock on the generating computer) is within plus or minus 10 minutes of the time of evaluation (with respect to the clock on the evaluating computer).
PassTickets can be recognized by RACF, ACF2 and TopSecret.
The PassTicket applies to only one application (unlike the "regular" password).
The algorithm that generates the PassTicket is a function of:
To be able to generate a PassTicket, you need to define a shared key or secret between the systems on which the client and the security server are running. This key depends on the application and optionally (and hopefully) on the user.
It is the same as the profile you would put in the RACF APPL class for protecting the access to the application. For TSO, it is TSO + SMF ID.
Applications that don't specify an APPL parameter get a default APPL, for PassTicket purposes only, of "MVS" followed by the system's SMF ID. This works also for batch jobs.
For USS applications, such as Websphere, FTP, etc., the application name is OMVSAPPL.
If it's on Mainframe, then you can use the generation routine that RACF (and TSS 5.0 and ACF2 6.2) provides. Here is an example :
* PASSTICKET GENERATION
GEN DS 0H
SETAMOD 31
MODESET KEY=ZERO,MODE=SUP
L R15,16 Get pointer to CVT
USING CVT,R15 Make CVT addressable
L R15,CVTRAC Get pointer to RACF CVT (RCVT)
USING RCVT,R15 Make RCVT addressable
L R15,RCVTPTGN Get pointer to PassTicket rtn
CALL (15),(USERID,APPNAME) Call PassTicket generator
ST R15,RC SAVE RETURN-CODE
STM R0,R1,PTKTFLD Store PassTicket in PTKTFLD
MODESET KEY=NZERO,MODE=PROB
SETAMOD 24
* DATA
DS 0D
PTKTFLD DS CL8
USERID DS 0CL9 Userid Structure:
USERIDL DS AL1(7) -> NUMBER OF USERID CHARACTER
USERIDN DS CL8'IBMUSER '
APPNAME DS 0CL9 APPL Name Structure:
APPNAMEL DS AL1(4) -> NUMBER OF APPNAME CHARACTER
APPNAMEN DS CL8'IMS1 '
RC DS F Return Code
LTORG
CVT DSECT=YES,LIST=NO
ICHPRCVT
*----------------------------------------------------------------------*
* Return Code + Description *
*-----------------+----------------------------------------------------*
* 0 Successful completion. The resulting session key is*
* contained in general purpose registers 0 and 1. *
*-----------------+----------------------------------------------------*
* 4 Incorrect PassTicket *
*-----------------+----------------------------------------------------*
* 8 No PTKTDATA profile found for the application *
*-----------------+----------------------------------------------------*
* C No task or address space ACEE found, and the ACEE *
* pointer was not specified on the input parameter *
* list. *
*-----------------+----------------------------------------------------*
* 10 Caller is not authorized *
*-----------------+----------------------------------------------------*
* 14 The RACF PTKTDATA class is not active *
*-----------------+----------------------------------------------------*
The CICS Front End Programming Interface (FEPI), an integral part of CICS, may also be used to generate a PassTicket : EXEC CICS FEPI REQUEST PASSTICKET requests the external security manager to supply a PassTicket.
If you're talking about other platforms, then you have several options:
SETROPTS CLASSACT(PTKTDATA)
SETROPTS RACLIST(PTKTDATA)
RDEFINE PTKTDATA appl.group.userid -
SSIGNON(KEYMASKED(0123456789abcdef))
where appl is to be replaced by the application name (CICS, TSO+SMFID, etc.)
group and userid are the RACF group and userid,
and 0123456789abcdef (the Secured Signon application key)
should be replaced by a valid 16-digit secret key. Note that appl.group.userid
can also be replaced by appl.userid if the connection group does not matter.
SETR REFRESH RACLIST(PTKTDATA)
Now, the PassTicket generator must know the userid, the application name and the Secured Signon application key (which is the "secret factor" that must be kept in security).
IBM has also offered the possibility to replay the same Passticket. Although it defeats part of the security brought by the Passticket facility, it may help some sites faced to its limitations (a generator can generate only one Passticket per user per second, so if you try to logon twice within a second interval, you are forced to use the same Passticket). RACF requires then the PTKTDATA profile to specify APPLDATA('NO REPLAY PROTECTION.').
PassTicket profile names can be "qualified" with the user's group name and user ID. An application is no longer limited to a single key (as prior to RACF 2.2), but can now have different keys for different groups and users. Use of qualified PassTicket profile names is optional in that unqualified (application name only) PTKTDATA profiles can be used. In fact, it is possible to have both a qualified PTKTDATA profile name appropriate for a given user who is being authenticated and an unqualified profile name for the same application. In this case RACF uses either key in either profile to evaluate the PassTicket.
The passticket may not work because :
The most common cause for problems with PassTicket verification is differences in time settings.
Since your PassTickets are created on a UNIX or Windows (or etc.) machine and are verified by RACF on an S/390, you must take care that both machines have the same notion of UTC (Universal Coordinated Time, aka. Greenwich Mean Time). On your UNIX server, check the TZ setting and make sure it is set to the right time zone.
On your OS/390 or MVS system, you have two time sources: the TOD clock and the local time. The TOD clock must be set to UTC, the local time must be set to the correct offset from UTC and the offset needs to be changed in the CLOCKxx member in SYS1.PARMLIB.
PassTickets are created with a UTC timestamp. If the system that creates the PassTicket has a different notion of UTC than the system that verifies the PassTicket, you'll never get a match.
My offering is a RACF Passticket generator for Windows, a software-only implementation of a RACF Passticket generator : "PTKTGEN".
Highlights :
- PTKTGEN is written in REXX ; it invokes a freeware product for encryption functions. I have used Regina Rexx from Beyond.com, but I think other REXXes should also work.
- For the moment, PTKTGEN runs in a DOS window, but I plan to provide a more "flashy" interface in the weeks/months to come, the main point was first to efficiently generate the passticket...
- It is delivered in a PTKT.ZIP file (210 Kb). Instructions are provided in the README.TXT file.
The 09/09/2001 bug has striken ! You will get an error in PTKTGEN.REX because more than 1 billion seconds have elapsed since 1/1/1970 (1 billion = 1000000000 represents 10 digits, and REXX by default handles only 9 digits : "numeric digits 9" is the default value).
The fix consists simply in adding in PTKTGEN.REX a statement : "numeric digits 20" before the "datesec" variable is used.
Conditions :
- I grant you the right to use PTKTGEN provided that only ONE copy of PTKTGEN is used in your company. For multiple copies, contact me.
Warning : on the PC, Secured Signon application keys are stored in a "userid.INI" file (where userid is the RACF userid). This is sensitive information that you should protect. This is why I call PTKTGEN an "unsecure Passticket generator".
It is assumed that the secret Secured Signon application keys (stored in userid.INI) can not easily be compromised. These keys, once compromised, would allow ANYBODY to generate passtickets and to use your userid.
A possible solution is to store the userid.INI file on a disquette that you keep in security. Copy the userid.INI file on the disquette, scratch the hard disk version, and update PTKTGEN.REX suppressing the line : " path_for_keys = '.\' " to force it to read the version on disquette.