83-10-31 User Authentication: A Secure
Networking Environment
Ellen Bonsall
Payoff
After identifying network security requirements, defining the security process, setting policies and procedures, and defining remote access security terms, the next step is to examine the types of network security and user authentication that can be incorporated into an enterprisewide solution for protecting information. The choice of technology and products must support authentication for multiple uses with system scalability and internationally recognized standards.
Introduction
After identifying network security requirements, defining the security process, setting policies and procedures, and defining remote access security terms, the next step is to examine the types of network security and user authentication that can be incorporated into an enterprisewide solution for protecting information. The choice of technology and products must support authentication for multiple uses with system scalability and internationally recognized standards.
In addition to the simple, reusable passwords and user IDs common to all operating systems and computing devices, are a variety of user authentication techniques that can be employed to ensure adequate system protection as remote users are added. It is common practice to combine reusable passwords, user IDs, and these other methods for a more secure networking environment:
· Dial-back security. · Caller ID and ANI. · Encryption.
· Two-factor, challenge-response authentication.
Dial-Back Security
After a user has been identified through a simple ID process, a modem can dial-back for an additional level of verification. Users must be at a predetermined phone number to receive the dial-back call. If an intruder tries to initiate the process and is not at the proper phone number, he or she will not receive the call back. This low-cost method of security was acceptable in the past before the widespread use of the Internet and when its users did not roam about as much. Most remote communications packages support dial-back as a security feature, and some modems support dial-back at the hardware level. With so many software and hardware platforms supporting dial-back, it is easy to implement, but not very secure. Dial-back security can be spoofed by call forwarding; can be spoofed if the phone system cannot initiate a hang up at the right time; is difficult to administer with large call-back lists; is not effective for users who travel to unplanned call-call-back locations (e.g., hotels); and generates complicated phone billing issues. In addition, there are many easy methods to gain access to phone numbers and to change an individual phone number at a remote user location.
Caller ID and ANI
Caller ID services are increasing across the nation. Known as Caller Number Delivery (CND) or calling line identification, information is passed to the receiving end of the call between the first and second rings. The CND information is passed directly from the phone company switch, which supports the caller, to the switch supporting the recipient of the call. The recipient's switch then passes the CND information to the user's premises.
Another service, Automatic Number Identification (ANI) has been available for years to businesses as a component of certain types of phone lines. These services can be used to identify the phone number used by incoming callers. In theory, if not in practice, this could allow a remote user's location to be validated before the host's modem answers the phone. This makes spoofing nearly impossible. There is no actual connection between the caller side and the receiving side before the phone is picked up. CND verification devices sit between the phone system and the host's modem. These devices can be set to reject a call if the CND information does not match the remote user's table. A solution using CND for security could reside at the modem, a black box on either side of the modem, or in software.
However, CND is not available universally, and is not likely to be so in the near future. In addition, a lot of privacy issues are involved. People can even request CND blocking. Such a plan is not feasible if multiple phone company areas are concerned, is difficult to administer to large remote user lists, and is not effective for users who travel to calling locations that are not pre-defined. Therefore, this should not be considered a viable, easy-to-implement user authentication solution.
Encryption and User Authentication
Encryption algorithms use “keys” to encode and decode a sequence of bits. In private-key encryption, the key remains secret. With public-key encryption, the key used to encode is known by everyone, and the one used to decode is known only to the user. Many modems and LAN operating systems use encryption to protect data sent between networks, but for the purposes of negotiating an enterprise network on a daily basis, encrypting everything is not practical.
Imagine having to encrypt nearly every communication, every file, everything created on the network, every day. Even if time, systems, and resources permitted such feats, that still would not keep intruders from attacking a network or its applications. Without user authentication, access to files, encrypted or not, is still possible. The following discussion looks at encryption as it is involved with user authentication and one-time passwords.
When a remote user logs into a network over the telephone line, data travels over the line in clear text. Intruders can tap into the connection and steal common IDs and reusable passwords. To prevent this, remote access authentication systems use a two-factor, challenge response process along with encryption to scramble password data. Employing either public or private algorithms in the process, authentication tokens generate one-time-use-only passwords that are used to confirm or deny access to users. By using encryption, a user authentication system can scramble passwords, PINs, and other small messages to send them safely over unprotected telephone lines. (Some tokens can also send encrypted credit card numbers for use in consumer-based electronic commerce applications.)If a hacker were to capture the encrypted information successfully, he or she would have to break the encryption scheme to use the data. If the authentication system employs proven algorithms and an asynchronous-based process, hacking the data is essentially impossible. Even if it were possible, the time and resources to hack a one-time-use password would not pay off, because the password could not be used a second time anyway.
Private Versus Public Key Encryption
The two kinds of encryption are private key and public key. It is safest to choose authentication products based on widely used algorithms, such as the Data Encryption Standard (DES)--a private key encryption scheme- -or Rivest_Shamir-Adleman (a public key cryptosystem named by its inventors, Rivest, Shamir, and Adelman, who hold the patent).
DES, the industry-standard private key encryption scheme, relies on an algorithm-based 64-bit key. Fifty-six bits are used for actual encryption and decryption, and the other eight bits are reserved for parity checking. Each bit is randomly generated. There are literally quadrillions of possible combinations. Each time data is run through the key, the key produces a unique, one-time result. With such a private key system, data is encrypted and decrypted according to one unique key. Users encrypt passwords by using their own, unique keys and then by sending the encrypted data to the host authentication server, which must have the same key to decrypt the data. Because anyone with access to the key can decrypt the data, the key must be kept private. In considering an authentication system, no one outside of the organization should have access to these private keys. Some systems require that vendors maintain user data bases. In addition, caution should be exercised if considering user authentication systems that employ private key, proprietary algorithms that are neither proven over the long run (as in decades of use) or about which little is known. If the encryption algorithm has not been employed for a long period of time, and if independent experts have not evaluated its reliability and published the results, the dependability of the overall system should be questioned.
Public key encryption relies on a unique pair of keys that can only work with each other- -a private key and a public key. Once data has been encrypted, only the matching private key can decrypt it. In such a system, users are assigned unique private keys, which must be kept secret too. The matching public key is copied and distributed to fellow
employees (i.e., business partners, suppliers, or investors) or stored in an authentication device (i.e., token)or in a host key server. When a user wants to send a private message, he or she encrypts the data by using a copy of the recipient's private key. As a result, only the intended recipient can read the data.
Two-Factor, Challenge-Response Authentication
What is a two-factor, challenge-response authentication process, and what does it look like in a complex environment? Imagine two IBM mainframes loaded with sensitive
information. At the same site, add a 500-node Ethernet LAN connected to a Tricord Power-Frame ES-5000 superserver running NetWare 4.1. Attach 200 users to a Digital VAX 6000 Cluster in the same computer center. Toss in a few hundred users who need remote access to information on the mainframes through four protocol converters. How can hundreds of remote users, who may be located anywhere in the world, be authenticated?
A remote user (e.g., a marketing coordinator attending a trade show) might have to call in for information he or she has stored on the LAN. He or she plugs the PC into a phone line and calls into an authentication server by using a modem and a commercial software product, such as PCAnywhere, logging in with a user ID (just as he or she would if sitting at his or her desk in the office). The remote user is now identified.
The dedicated authentication server (or an authentication software server solution) intercepts the call and issues a random numerical challenge. Authentication servers can restrict access with a combination of factors not normally present in gateway security. Authentication servers authenticate through a two-factor, challenge/response process during which users communicate with the authentication server through tokens and their PCs. A comprehensive user data base that contains information on all remote users is stored in the authentication server, which depending on the vendor can authenticate those users through a combination of user ID, password, password aging, call-back, time of day, and date
range. It is up to the security administrator to set the specific security parameters by choosing any or all these factors if they are available.
This user authentication solution provides a more secure process than relying solely on reusable passwords and common IDs. Without a dedicated hardware or a software
authentication server, who is to say that the marketing coordinator(mentioned previously) is actually who he or she says he or she is? None of the traditional modes of security are in place when a remote user calls in with only an ID or a reusable password between the user and the network. No receptionist checks his or her ID; no building guard stands there to recognize him or her; and no one is sitting in the office or cubicle next to him or her to raise an alarm in the presence of a stranger. Two-factor, challenge-response authentication provides levels of security that cannot be found with traditional gateway security. Two-factor, challenge-response authentication provides better security than PC-to-PC security, traditional passwords, user ID, or native communications server security.
What is two-factor, challenge-response authentication? The following describes what happens during the two-factor, challenge-response authentication process. The user has a Personal Identification Number (PIN) that only he or she knows. With the PIN, he or she activates his or her token, which can be either a hand-held key or a software key loaded directly onto his or her PC. The PIN identifies him or her as the owner of the token. An unauthorized user cannot activate the token, because he or she does not have the PIN. Only the user and the token itself know the PIN. When evaluating two-factor authentication token systems, tokens should allow the user to enter—or change at will- - his or her PIN. Not even the network administrator should know a user's PIN. Moreover, PINs should not be transmitted over telephone lines, because, in some cases, it is possible to capture them and user them later.)
This makes up the “two factors”—something the user knows(i.e., the PIN) and something the user has in his or her possession (i.e., the token). After the user is
identified, the network authentication server issues a random, alpha-numeric challenge that requires a specific response that can only be calculated by a token with the identical, user-specific encryption key as stored in the network authentication server. When the marketing coordinator enters the response that his or her token generates, he or she is authenticated, but only if the response (i.e., password) matches the password expected by the
authentication server. Only the coordinator's token (loaded with his or her unique key) can calculate the same response (i.e., password) that the authentication server calculates. There is no possibility for someone to steal or discover such a password, one that is created on the spot by using an encryption algorithm; one that is issued only once; and one that can never be used again.
Standards Compliance
Authentication products should be based on internationally recommended standards. These provide a better solution than systems based on proprietary technology, especially if scalability is required and if it is expected to accommodate future applications based on emerging worldwide standards. Proprietary technology does not provide the required cross-platform interoperability demanded by today's open systems and complex distributed networking environments. An authentication solution must operate on a variety of hardware platforms, including mainframes, midrange computers, workstations, and PCs, and with a range of operating systems, including Microsoft Windows 3.1, Windows 95 and Windows NT, and UNIX systems (such as Sun Solaris, SunO/S, Hewlett Packard HP/UX,
IBM/AIX, OS/2, and Berkeley Software Design O/S).
The authentication solution should also comply with internationally recognized security standards, such as those promulgated by the International Organization for Standardization (ISO) and the American National Standards Institute(ANSI). The authentication solution should comply with these internationally recognized standards:
· ANSI X3.92 in a chosen algorithm. · ANSI X9.17 for secret key management.
· ANSI X9.9 for the calculation and display of dynamic passwords. · ANSI X9.26 for the challenge response process.
These standards provide the highest level of security, interoperability, and ease of implementation in the marketplace. In addition, international standards compliance makes existing systems compatible with other enterprise networks, while it simultaneously provides for scalability in the future.
Conclusion
A lot of questions need to be asked before choosing an user authentication process that will work in today's multiplatform, multiple-use networking enviornment.
Does the organization really want proprietary software and hardware authentication servers? The major drawback of such systems is that they do not operate across multiple networking platforms in all communications environments, and they may not be compatible with future security requirements. As time passes, it may be necessary to purchase
additional hardware or software for multiple access points.
Author Biographies
Ellen Bonsall
Ellen Bonsall is the Marketing Director, U.S. Operations for ActivCard, Inc., San Francisco, CA.
