For many organizations, autonomous network access solutions have evolved independently across regional or organizational boundaries. As a result, traveling users are forced to adapt to the technical idiosyncracies of each remote access environment, while network administrators are required to perform tedious and repetitive management functions in support of mobile users.

Enterprise-level authentication is a new capability introduced in the ACE/Server 3.0 release that permits a distributed collection of co-operating ACE/Servers to provide a single, enterprise-wide user authentication service. This feature provides end-users with a single, easy-to-use authentication process regardless of the point of entry, while significantly simplifying security administration.

This white paper provides an overview of the Security Dynamics authentication system and discusses the features and benefits of ACE/Server's enterprise authentication capability. It assumes a basic knowledge of Security Dynamics' network security system.

The Security Dynamics Authentication System

In this section we review the main components of Security Dynamic's authentication system and provide a framework for the description of enterprise authentication. To facilitate our discussion, we introduce a generic client server application: XYZ client and XYZ server.

To enable trusted third party authentication, the XYZ server acts as a client to the ACE/Server, sending user I&A information to the ACE/Server and receiving a verdict regarding the user's authenticity. Systems that act as clients to the ACE/Server for user authentication are called "ACE agents." The client-server interaction between an agent and an ACE/Server replaces what would ordinarily be accomplished via a password lookup in a local user account database. The typical sequence of events in the authentication of an XYZ client to an XYZ server is as follows:

1. The user starts an XYZ client program on their local system.
2. XYZ client connects to the XYZ server program.
3. The XYZ server instructs the XYZ client to prompt the user for authentication.

At this point:

1. The user enters authentication information into the XYZ client.
2. The XYZ client forwards user authentication information to XYZ server.
3. The XYZ server forwards user authentication information to the ACE/Server for verification.
4. The ACE/Server responds - confirming or denying the user's identity.
5. The XYZ server sends an authentication status message to the XYZ client and permits further access by a successfully authenticated user.
6. On successful authentication, the XYZ client might display a welcome message from the server, failed authentication attempts usually cause the XYZ client to again prompt the user for authentication information.

This simple paradigm for referring authentication decisions to a master authentication server has numerous security applications. Different security applications are realized by providing different contexts for the generic XYZ client server protocol.

The ACE agent runs on a network access server providing secure dial-up networking. The authenticated user is permitted terminal access to designated hosts or remote node access to the corporate network.

Remote users may already have IP access to public networks, e.g. through their own ISP or by connecting to some other Internet accessible network. ACE/Agent software provides authentication at corporate firewalls. The firewall system challenges remote users for authentication prior to proxying application-layer services, or forwarding selected IP datagrams.

System login routines can be augmented to support the ACE agent protocol. Mission critical services can avoid the weaknesses of password based authentication schemes. Administrative accounts can acquire enhanced access protection and auditing capabilities.

WebID brings two-factor authentication to the World Wide Web. The leading WWW servers incorporate support for protecting server resources with SecurID authentication. The Webmaster can designate individual documents or whole directory trees for protection by WebID. Users authenticate upon first access to a WebID protected document and a WebID generated cookie ensures transparent protection throughout the rest of the browsing session.

The ACE/Agent - ACE/Server protocol

ACE agents and ACE/Servers communicate with one another in a simple transaction-oriented protocol based on UDP. Each transaction consists of a single request/response pair. Although there are multiple request/response types (for error handling and administration), the most important are those associated with a typical successful authentication. The process is as follows:

• The agent generates an authentication request containing the agent's name, the user's name, and the user's passcode.
• The agent encrypts1 this message in a key shared only with the ACE/Server and sends the message to the ACE/Server.
• The server decrypts this message with the shared key and verifies the correctness of the user's authentication attempt.
• The server builds a response indicating success or failure, encrypts the message in the shared key, and sends the response to the agent.

Enterprise Authentication

The simplicity of the ACE/Agent / ACE/Server protocol makes it possible to introduce "proxy" authentication functionality in the ACE/Server. In this context, proxy simply means that when one ACE/Server isn't capable of verifying the authenticity of a username/password combination, it refers the request to the server that is capable of verifying that user's authentication request and then relays the response back to the originating agent. Enterprise authentication services are enabled when ACE/Server administrators configure their servers to provide cross-realm2 authentication.

Consider the following scenario. A user whose home realm is New York travels to London and will access the corporate network through the local network access server.

• The user connects to the London network access server.
• The London network server is an agent of the London ACE/Server and forwards the user's authentication request to the London ACE/Server.
• The London ACE/Server searches its local user database but does not recognize the user. However, this server is configured to support enterprise authentication and will perform cross-realm authentication with both the New York and LA ACE/Servers.
• The London ACE/Server now acts as a client to both the New York and LA authentication realms by forwarding copies of the authentication request to both of these ACE/Servers.
• The LA ACE/Server fails to recognize the NY user and generates a response indicating an unrecognized user. The NY ACE/Server, however, does recognize the user and processes the request normally, returning the response status to the London server..
• The London server returns the response to the original network access server.

Starting with ACE/Server v3.1, subsequent logons at the remote site will not cause a broadcast to all sites. Upon authentication of the first logon, the user's home realm information is cached locally - the user isn't registered locally. The next time the employee logs on, the broadcast is only to the home realm stored from the last logon. This caching of information locally reduces network traffic if you have a lot of remote users on your system.

If the employee is not authenticated, then the ACE/Server broadcasts to all sites and you begin as usual. Further, information on remote users is reportable by the local administrator and there is a mechanism to purge the remote user information by user or based on time since last log on. Users only need to be registered at their home site, reducing the risk of duplicating user information at multiple sites.

There are several key points associated with network authentication.

• Since enterprise authentication is facilitated by protocol enhancements between ACE/Servers, enterprise authentication is completely transparent to both the end user and ACE agents.
• ACE/Servers recognize proxied requests and do not perform additional proxying for unrecognized users. Thus, resolving an authentication request requires at most one level of indirection.
• Audit log records indicating the status of proxied requests are written by both ACE/Servers supporting the request.

A Comparison of One-Time Password Systems and Challenge/Response Systems

There are two primary models for token-based user authentication systems. These models place different requirements on both the end user and on the authentication server(s) supporting those users.

One-Time Password Systems. In one-time password systems, a user token displays a "current password" which the user simply enters in any context that would ordinarily require a conventional password. The server system can calculate the current password on demand and verify the authentication request. However, it is incumbent on the authentication server to maintain sufficient state to ensure that a password cannot be reused. This means that each successful one-time password authentication requires an update operation to the authentication database.

Challenge/Response Systems. In a challenge/response model, the user first receives a challenge (usually a pseudo-random number) generated by the authentication server. The challenge displayed to the user is then copied by the user into his/her token. The token then calculates and displays a response which depends on the challenge. The user then copies this response back into the application prompting for authentication information. The server system calculates the expected response and compares with the response submitted by the user. However, since challenges are generated at random by the server, attacks associated with replaying authentication information are not an issue for well designed systems. As a result the server does not need to retain information regarding which "passwords" have been "used."

The relevant differences between these two approaches can be summarized very succinctly.

• One-time password system have significant ease-of-use advantages but each password verification is coupled with a write operation to the authentication server database.
• Challenge response systems require only read operations on the associated authentication database but are laborious and error prone for users.

In environments with a single authentication server, the distinction between read-only versus read-write operations on the authentication database are largely irrelevant. All authentication transactions are performed relative to a single database.

Distributed Authentication Services
In environments supporting distributed authentication services, the server-side differences between one-time password and challenge response authentication systems become more apparent. Consider a distributed networking environment with multiple authentication realms connected over a wide area network.

Challenge/response systems only require read access to the associated authentication database (except for relatively infrequent administrative operations). As a result, the natural way to support distributed operation is to securely replicate the authentication database to wherever the information is needed. In short, bring the database to wherever the authentication requests are verified.

One-time password systems require write operations for each authentication request. Furthermore, this write operation is essential for maintaining the integrity of the one-time password system. These update operations occur at the same rate that users authenticate and cannot be deferred to some more convenient batch schedule. In this context, it is desirable to proxy authentication requests. In short, bring the authentication request to the appropriate database for verification. This is the enterprise authentication approach.

The main point is that there are fundamental technical differences between challenge/response authentication systems and one-time password authentication systems. These distinctions require that the two authentication models diverge in their approach to providing distributed authentication services. For challenge/response systems, database replication is the "right" solution. For one-time password systems, proxy authentication is the "right" solution.

Advantages of Enterprise Authentication
Enterprise-wide Authentication Service. Enterprise authentication services allow network administrators to build a unified distributed user authentication service for all security enhanced applications in the enterprise. This enhanced service can be overlaid on existing ACE authentication systems and is transparent to both end users and existing agent software.

Scalability. The ACE/Server's integrated relational database design can support tens of thousands of users. Since enterprise authentication services can support up to 20 cooperating ACE/Servers, authentication services can be deployed for very large user populations.

Reliability. The ACE/Server is the most reliable authentication server in the industry with reports from customers of continuous operation in excess of six months. Furthermore, ACE/Servers can be configured with a backup server enabling transparent, hot-standby operation. In the unlikely event of failure of a primary ACE/Server, authentication functions can be performed by the backup server. When the primary server becomes available again, the master and slave transparently synchronize databases and the backup server resumes responsibility for processing authentication requests.

Immediate Revocation. Since each authentication attempt by a given user is adjudicated by that user's home server, all access control decisions are authoritative. In environments where user authentication data is mirrored or replicated across multiple databases, temporary inconsistencies between database instances arise. As a result, a disabled user can continue to gain access to protected resources until updates on that user's privileges are propagated to all authentication servers.

Flexibility. Enterprise authentication services can be enabled with minimal impact on the current management and administration of ACE/Servers. Cooperating server administrators need only enable cross-realm authentication functionality between ACE/Servers and agent software located anywhere in the network can authenticate users located anywhere in the network.

Limitations of Enterprise Authentication

Enterprise authentication relies on the availabilty of the underlying network for proxying authentication requests between ACE/servers. This means that an ACE client attempting to verify an authentication request for a user in a remote realm will fail when network connectivity to the remote ACE/Server is lost.

One way to provide continued authentication services in the presence of network failures is to deploy redundant backup servers. However, since the current ACE/Server architecture limits each primary to at most one backup server, it is sometimes difficult to design enterprise authentication systems which can tolerate arbitrary network failures. SDTI will address this limitation in future releases of the ACE/Server.

Conclusions

Modern corporate networks are experiencing an ever increasing demand for strong user authentication technology. This demand is fueled by both increased numbers of mobile workers and increased diversity in the methods for accessing data on corporate networks. Security Dynamics' enterprise authentication technology allows corporate IT managers to build scalable, enterprise-wide authentication services capable of authenticating and auditing any user access at any location in the corporate network.

Security Dynamics Technologies

Security Dynamics is the leading provider of enterprise and network data security solutions. Security Dynamics' solutions help companies conduct business securely, protect corporate information assets and facilitate business-to-business electronic commerce. Security Dynamics' products employ patent-protected SecurID token technology and ACE/Server® software or hardware access control products to authenticate the identity of users accessing networked or standalone computing resources. With 2 million users in 2,000 companies, Security Dynamics is the world leader in two-factor user identification and authentication. RSA Data Security Inc., a wholly owned subsidiary of Security Dynamics, is the world's brand name for cryptography, with more than 80 million copies of RSA encryption and authentication technologies installed and in use worldwide. Security Dynamics and RSA can be found on the World Wide Web at http://www.securitydynamics.com/ and http://www.rsa.com/, respectively.