August 2000
Two-Factor Token Authentication on e3000
State-of-the-art security is possible using tokens, agents and RSA secure servers with MPE/iX
By Andreas Schmidt
This article describes a way to build a security barrier around your HP e3000.
It is based on material offered by Security Dynamics (www.rsasecurity.com), and on my own HP 3000
experiences in a project to roll out a Two-Factor Token Authentication to all
platforms for a big company in the chemical industry, one which chose NT and HP
3000 systems as pilots.
Background
Today it’s a risk to trust only static passwords. Some studies have shown that approximately 60 percent of big companies have detected a security violation in the last two years, and more than 80 percent still use static passwords, especially to connect to the network. So it’s a good approach not only to rely on static MPE security, or third-party security solution passwords, but also to introduce a Two-Factor Token Authentication.
Two-Factor Token Authentication
Authentication is the process to verify the identity of users. On the Internet, cookies can provide automatic authentication for user names and passwords having been registered at a site, especially with SSL (Secure Socket Layer) encryption for things like credit card information.
On intranets, the authentication could happen with simple passwords, along with tokens or smart cards, or with biometrics that utilize the individual’s physical characteristics such as finger-print or retina.
Because passwords can become cracked or sniffed on the WAN/LAN, all methods using static authentication are not secure. The Two-Factor Authentication requires two factors before an user will gain access to a network or system:
• The person needs to have something: a token which produces a tokencode. Such a tokencode will change about every minute.
• The person has to know a PIN. This Personal Identification Number is unique and only valid for the physical token the person possess.
If an individual needs access to a server or a network component, they must log on to an Authentication Server or Agent and enter the PIN and the actual tokencode. As soon as the token has been recognized by the logon name and the Authentication Server has accepted the code combination, it cannot be used a second time. A sniffer has no chance to use the same combination of PIN plus tokencode.
The vendors of such authentication environments (server, agents, and tokens) ensure that each authentication token is unique and it is impossible to predict the value of a future tokencode by recording prior tokencodes. Thus when a correct tokencode is supplied, there is a high degree of certainty that the person is the valid user in possession of the physical authentication token and the remembered PIN.
One environment provider is RSA Security Dynamics, offering a SecurID Server, Agent, and Tokens.The heart is the RSA ACE/Server, the authentication engine on the network. It runs on different Unix flavors and Windows NT or 2000. This server is the management component of the RSA SecurID product family, used to verify authentication requests and to administer policies for enterprise networks.
All network components which should become authenticated must be defined on this server and become RSA ACE/Agents. When a person attempts to access a protected system, this software agent initiates an RSA ACE/Server authentication session instead of a basic password session. (This is true for Unix and NT, but not in this case for MPE, as we will see later.)
The user is required to enter the user name and instead of a static password, the current tokencode from the authentication device (the token) plus the PIN. The agent software hashes the information supplied by the user with additional data known only by the protected device (agent platform). It then transmits portions of the hashed information to the RSA ACE/Server, which approves access when the information is validated. The user is granted access, and this is logged onto the Server as well.
The last component is the physical device the user possesses, the authenticator or token. Many forms are offered. The one most used is a key fob: a device with a built-in chip and an LCD window to display the tokencode, small enough to be attached to a key ring. Others are credit card look-alike devices. The latest edition is software for palmtops generating the actual tokencode. Using any one of these devices, a person must possess them to authenticate, employing the same patented algorithm for encrypting and hashing the tokencode.
Authentication Advantages
Having installed such a system on all devices before access for an individual is granted, the security of a company’s network will be drastically improved. The four primary benefits are:
• Enterprise Authentication: Only those persons can access the devices when they are authorized to possess and use a token and PIN.
• Access Control: This is essential to protect against outsider attacks or malicious employees.
• Evasion of Attack: Hackers will try to unexpectedly gain access to a network. The Server identifies threat conditions, which are reported to the logs and alert the system manager.
• User Accountability: Damage may be done using an employee’s password without the knowledge of that employee. However, by logging the authentication process which requires PIN and tokencode, it provides more assurance of employee involvement in any unauthorized activities. The knowledge of this and of the comprehensive logging helps employees recognize their accountability for information security, so that their behavior is more secure.
The HP e3000 Agent Solution
The chemical company, which CSC is providing with IT services, decided to roll out Two-Factor Token Authentication over all platforms within one year. NT and MPE were selected as pilots: NT because of the large number of servers running that environment; and MPE because of the thinking that this platform might be different from all others and more difficult to implement. However, the company also recognized the importance of running its 3000-based Order Fulfillment Process with a lot of different outside partners.
RSA’s first attempt to develop an agent for MPE was very simple: A token had to become configured for a combination of MPE-USER-ID.MPE ACCOUNT. This combination could not be reused on another token. It was not possible to use wildcards or to add SESSION-IDs or MPE-GROUP to have a complete logon string. Because of the MPE characteristic to share logons (on all levels of capabilities) this version of the agent was not what we were looking for. (More drastically: This agent could not function for the MPE platform).
The second attempt was much better: everything was changed to the chemical company’s already-existing Security/3000 setup. Now Security/3000 invokes the RSA Agent to contact the RSA Server. It transmits either the SESSION-ID or the MPE-USER-ID as the name of the token. If the token is known and allowed to access the HP 3000, the agent asks the user for the current tokencode plus PIN.
This agent also functions without Security/3000 by adding some lines to the System’s Logon UDC. This drops some additional functions in combination with Security/3000, like verifying a user profile in any case (SESSION-ID,MPE-USER-ID.MPE-ACCOUNT is defined as allowed logon in Security/3000, all others will be refused before starting anything), but it will work.
One thing is essential: The RSA Agent for MPE does not replace the MPE password process like it does for Unix or NT! It is activated first when the HELLO string has been entered and the MPE password hurdle has been passed (Account, User, and/or Group Password) and (as an option) the basic check within Security/3000 for profile existence is passed. Now any other logon UDC functions are invoked, and this activates the RSA Agent.
Having Security/3000 in place is a good idea to replace the session passwords (if any) by supplying the tokencode.
Not having session names in place, the RSA Agent will add an additional password. I do not recommend eliminating the MPE password — it’s still a fence around your system and is needed for batch security (depending on the streaming security you have in place).
Having activated the RSA Agent, a logon sequence will look like Figure
1.
The setup within Security/3000’s SECURCON.DATA.VESOFT file is shown in
Figure 2.
Figure 1
SYSTEMA:hello paul,manager.sys
ENTER USER (MANAGER) PASSWORD: xxxxxxxxxxx
HP3000 Release: C.55.00 User Version: C.55.00 FRI, JUN 9, 2000, 7:34 PM
MPE/iX HP31900 C.05.08 Copyright Hewlett-Packard 1987. All rights reserved.
*************************************************************
This is a private computer facility.
Access to it for any reason must be specifically authorized.
Unauthorized access to this computer facility will expose you
to criminal and/or civil proceedings.
All information contained in this computer system,
including messages, is the property of the company.
The company reserves the right to access and disclose
all information sent through or stored in this computer
for any purpose.
************************************************************
********************************************
You are at: Bad Homburg SYSTEMA Series 960
********************************************
Enter PASSCODE:
PASSCODE Accepted
Welcome! You are now signed on.
END OF PROGRAM
SYSTEMA:
Figure 2
(* Setup for the RSA ACE SecurID Agent on HP3000 *)
(* ============================================= *)
(* Usersets if needed and wanted for later use *)
$DEFINE-USERSET MPESEC &
@.ACCOUNTA+@.ACCOUNTB
(* SEC/3000 Session Names to identify individuals *)
(* 1st line: all Online Logons *)
(* 2nd line: Accounts secured with MPE Methode *)
(* 3rd line: general Exceptions *)
(* 4th line: AM user of MPE Methode (2nd Userset) *)
$FORBID
"MPE('/var/ace/sdshell ![DWNS(HPJOBNAME)]') <> 0"
"SDI ACE Failed"
@.@&ONLINE-LDEV=20-LDEV=21-&
!MPESEC-&
@.TELESUP-SYSTEMB,XEALRMON.XFER-M,@.XFER-S,@.XFER
!MPESEC&ONLINE&CAP=AM
(* MPE UserIDs to identify individuals *)
$FORBID
"MPE('/var/ace/sdshell ![DWNS(HPUSER)]') <> 0"
"SDI ACE Failed"
!MPESEC&ONLINE&CAP<>AM
(* Needed for both Methods *)
(* Exception Line: general Exceptions *)
$FORBID
"IVAR(';SECURID',1) = 1"
"Invalid SecurID PASSCODE"
@.@&ONLINE-LDEV=20-LDEV=21-&
@.TELESUP-SYSTEMB,XEALRMON.XEXFER-M,@.XFER-S,@.XFER
Here are our detailed notes on the Security/3000 configuration.
$DEFINE-USERSET: If in your current setup you identify individuals by their session name or their MPE-USER-ID, it’s a good idea to define a userset for later use.
$FORBID: in this section for all accounts, where the session name is used to identify an individual, the sessionname is downshifted (convention in defining the token on the ACE Server), and the program /var/ace/sdshell, the RSA MPE agent, is executed. If the program’s error code is not equal to 0 the logon is rejected. This will happen if the tokenname the ACE Server received is not allowed to get access to this HP 3000 Server, or is not known at all.
This $FORBID process must be executed for all sessions (but not for batch logons) except console and remote console. (If the network is down, the agent cannot authenticate with the ACE Server) The exception is for all accounts identifying the individual by the MPE-USER-ID, and some special accounts like TELESUP or EDI accounts (here:XFER).
The second userset within this $FORBID statement includes all Account Managers using the MPE-USER-ID as identifier. Here it’s assumed that individuals share one AM logon like MANAGER or MGR and are distinguishable by the SESSION-ID. The next $FORBID defines the same setup for accounts where the MPE-USER-ID is used to identify an individual. The MPE-USER-ID is used for the ACE Server Authentication process. This is needed for all session logons in these accounts except the AM logons.
The third $FORBID checks a variable named SECURID. The ACE Agent sets this variable. If the tokenname is known and allowed for this server, but the code transmitted is wrong (PIN and current tokencode for the token identified by !HPJOBNAME or !HPUSER), the logon is rejected with the error message “Invalid SecurID PASSCODE” (variable SECURID is 1). Otherwise, the logon is accepted (and logged as successful on the ACE Server like all unsuccessful attempts as well), and the individual gains access to the HP 3000. This check must take place for all sessions except those on the two consoles and the general exceptions.
This setup is proven and stable. Because of Security/3000’s flexibility, it’s almost possible to build up any other existing security concept, as long as the current setup already distinguishes between individuals. If this is not the case for any reason, it’s obvious that this must be changed first because of the characteristic of all authentication processes.
A similar setup is possible within a System’s Logon UDC if Security/3000 is not in place. It will become more complicated (some IF clauses, etc.) and will require more effort in changing the setup. But it is possible because of the simple logic of the ACE Agent and ACE Server:
Do I know the name of the token transmitted ?
NO: “SDI ACE failed.”
Is this token allowed for that network component ?
NO: “SDI ACE failed.”
YES: “Enter PASSCODE:”
Is the right PIN and tokencode transmitted ?
NO: “Invalid SecurID PASSCODE.”
YES: “PASSCODE accepted”
Access granted!
What if the ACE Server and/or the network is not available for any reason, so that no authentication could take place? In this case, a system manager must use the specific parameter to bypass the system’s logon UDCs and disable this authentication security. Because of this, it’s highly recommended to switch off the ENFORCE LOGON UDCS setup in SYSGEN (enforcelogonudcs OFF), but to have a hard-to-guess password on all MPE-USER-IDs with SM (only one, I hope).
Also, it’s obvious that in this case the only password remains the MPE-USER-ID password (and/or ACCOUNT password). It’s probably a good idea to prepare a new SECURCON.DATA.VESOFT configuration file in advance, which will be needed in this case.
For our chemical customer it’s not probable that this will happen: A second ACE server is in place with an automatic switchover if the first is not available, and the network topology is redundant. Nevertheless, for smaller companies this may become an issue. It’s not expected that RSA will port its ACE Server software to MPE to avoid such problems, if only MPE is in use.
Rollout to an HP e3000 platform
Assuming that your company wants to have such an authentication for MPE, it’s important to plan this in great detail. There are some dependencies which need to be observed.
Depending on whether you want to keep existing naming conventions to distinguish between individuals (a convention like six letters of surname plus first letter of first name) which is used for SESSION-IDs or MPE-USER IDs, or if you want to create a new one for naming the tokens (like randomized names out of a name generator), you need to make changes more or less within the HP 3000 security setup. Remember, such an authentication may be used on a company-wide level serving all platforms in place (Mainframe, Midrange, PC, Network components) and that one individual possesses only one token for all platforms. This token name is unique and usable on all platforms.
In any case, you’ll need a complete inventory of individuals accessing the HP 3000, including all their individual logons. This list could be created out of Security/3000 itself. It needs to be consolidated and expanded with the individual’s token name. If a new naming convention will be used, all MPE logon profiles (SESSION-ID,MPE-USER-ID.MPE-ACCOUNT) must be changed accordingly.
It may also be the case that the existing logon characteristics (!HPUSER, !HPJOBNAME) are used within application configuration and setup. In this case this must be changed in parallel. And first the Authentication Process on MPE system level itself must be activated.
Lastly, everybody will cry if they used automatic logon scripts: They no longer work! Whether such scripts were allowed in the past (containing passwords) depends on your setup. If so, you have to convince the users that this behavior was never secure. If not, you can be sure that nobody will continue to use such scripts — at least no longer to supply the tokencode (but probably the PIN, which is not recommended)!
You may work on an application-per-application basis, but this will negatively affect individuals who work in more that one application. (For example, in Application A the SecurID token is already needed, but in Application B it still uses the old method.)
Don’t underestimate this effort! It’s very easy to understand the process, but it is hard to roll this out in a living production environment, possibly serving many different user locations. It’s possible, but it needs a dedicated and experienced project management team to deal with all the different groups involved: techies, network people, security admin people, HR, the token vendor, application support, user help desks, user supervisors, end-users and more. People management may become more important than technology management!
Summary
Two-Factor Token Authentication is a state-of-the-art process to avoid static passwords. RSA Security Dynamics provides an MPE Agent for this purpose which worked perfectly for us with Security/3000, but also with basic MPE security. The technical approach is not simple, but manageable. The main problems may arise during the rollout because of human behavior in keeping known procedures and avoiding changes, especially for security. But to stay on HP 3000 into the future, the effort is worth it, especially for better security.
Andreas Schmidt is a Computer Technology Specialist working for Computer Sciences Corporation, Bad Homburg, Germany.