Network Security: The First Steps to an International Authentication Framework
Articles and Tips: tip
Senior Research Engineer
Roger Schell
Security Development Manager
01 Feb 1998
The January 1998 NetNote entitled "15 Top Level Security Needs Identified by the Black Forest Group" outlined the critical security issues that were identified in the Black Forest Group's 15-point security requirements document. This NetNote goes into more detail on the first issue listed in the BFG document: how to establish an international authentication framework.
The Area of Authentication
At the data and information level, security is usually expressed in a security policy that protects the vital assets and individuals within the organization. The security policy controls user access to information, such as everyone's login passwords. Authentication is the process through which a user's identification is verified. However, to establish authentication, you must have something unique by which that person can be identified.
Most of the real security requirements in the area of authentication have already been scoped out and detailed. However, any authentication implementation needs to reflect a real tie-in to the users in order to hold them accountable for their actions. For authentication purposes, a user's actions on a computer must be attributable to that physical user. If the computer itself twiddles bits or connects when the user is not "in session," you still must be able to establish the computer's connection to the processes as they occur.
In viewing the Internet as a new environment for electronic commerce, very little of what is done today requires strong authentication. The Internet is fundamentally a weak authentication medium. Yet credit card transactions covered by a $50 liability limit are touted as the future of electronic commerce there.
Today many vendors make significant revenue by selling products into the authentication market. Some of these products are excellent when the environment for their proposed operation is well understood and can be controlled. Yet the majority of such products are misused and continue to promote the unsolved problems of implementing good authentication.
Globally acceptable authentication for electronic commerce must come in three parts:
User-to-server authentication
Client vs. user authentication
Heterogenous user authentication and access control
You can add to this short list an overriding concern that authentication must be applicable and legal in every country where it is used (either exported or imported), unless you expect to only do electronic business in unregulated countries.
User-to-Server Authentication
The first problem in establishing an international authentication framework is the need for strong authentication between the user and the server in today's ever-changing connectivity environment. Novell uses two types of authentication as part of the login process: bindery authentication in NetWare 3 (weak authentication) and Novell Directory Services (NDS) authentication in NetWare 4 (strong authentication). As defined here, "login" is performing all of the steps necessary for the client to build an electronic credential, as well as proof of the user's identity, so that user can access resources. It is safe to note that NetWare has built more authentication credentials (globally) than all other software to date!
In NetWare 4, the login process is performed by NDS. The process acts on behalf of the users, and the server provides background authentication to other servers on the network that the user needs. The NetWare 4 login process has been scrutinized independently by the National Computer Security Center (NCSC) and it has earned a Class C2 certificate relative to its architecture and the strength of mechanism provided.
Yet even with superior credentials, customers and vendors have noted the need for greater flexibility and interoperability during login. Since not all clients are NetWare clients and not all logins use LOGIN.EXE, there is also a need to administrate various forms of authentication. Current network authentication methods for the client should include those used by LDAP (Lightweight Directory Access Protocol), WEB, WBA, and other services. Yet current implementation techniques vary; Single Sign-On (SSO) concerns should be apparent to systems administrators and managers as the need for flexibility rises.
Client vs. User Authentication
Flexibility in the login process to other applications broaches the second point: client (workstation) vs. user authentication. There must be a clear distinction between authentication of the client (what machine is this?) and authentication of the user (who is using the machine?). Each additional authentication method, such as those using tokens, requires either a different authentication secret or re-entry to a different authentication process. After the initial login process, it should be avoided. Re-entry to other authentication secrets after the initial login process is a major fault in the security world.
The other aspect of "new" authentication techniques is that they often try to skirt the issue of client vs. user authentication with technology. For LDAP, the SSL (Secure Sockets Layer) technology is the proposed solution to ensure confidentiality during transmission of authentication secrets, and to ensure a confidential session once authentication is confirmed. By itself and without evaluated client components, SSL gives no assurance of confidentiality or correct authentication (this will be covered next month). SSL only assures that the user "believes" the session is private--not that it actually is. Various forms of malicious software can circumvent this "privacy."
Underlying support for the notion of a "trusted session" goes beyond mere authentication. The first level of confidence is confidence that a client-server session does not (within reasonable and configurable limits) persist when the user logs out. While support for an "absentee" session is desirable, a server must know that the user is absent (this is an extension of single-machine "batch processing" capability).
Intuitively, the first level involves confidence that "Bill is still there." The second level involves confidence that "Bill saw or generated and approves of this request." So the second level of trust is support for a "trusted transaction," i.e. that the real user (and not malicious software "stealing" the session or modifying messages) has generated a particular message.
Heterogenous User Authentication and Access Control
The third authentication area to solve is heterogenous user authentication and access control with the expansion of authentication as proposed by customers and partners. Through this process, non-Novell clients will authenticate to Novell Directory Services, which in turn will provide a single point of administration to control access to Novell-hosted services (directory, file, print, and so on).
However, as authentication is expanded to heterogenous platforms, the quality of authentication must recognize the origin and type of authentication used. Clearly, Telnet authentications with passwords running across unregulated media should not be allowed access to many types of sensitive information in existing computer systems. Systems administrators will therefore need a means to grade the different authentication schemes in regards to where and how users come to the system.
In addition to knowing where authentication originates, authentication must be extended from the client. This requires an infrastructure which allows the use of secrets to be securely stored at the client. Presently, Microsoft uses an insecure method by storing alternate passwords as files on the workstation's hard disk drive. This makes the exposure of authentication secrets relatively simple.
Another erroneous method is to store secrets like a password via a private key, as is done in the SSL implementation in Netscape. Protecting long-term secrets like passwords with keys on insecure operating systems and computers is no way to secure information. Clearly these initial attempts need to address the whole problem if they are be part of the solution and not more of the problem.
Conclusion
In an open electronic commerce environment (like the Internet), your computer connects circuitously to distant computers via an unknown route. The security of the transaction, even your login, is based on such assumptions as the belief in the privacy of the connection, the credulity of the business you are working with, and the authenticity of buyers (or sellers). Yet the ramifications of your actions along with your liability are virtually unexplained in today's electronic commerce. In fact, the problems of authentication and related liability in trade issues are widespread; they impose a difficult and persistent barrier to full electronic commerce because accountability is missing at almost every turn.
Authentication can be a major problem in establishing responsible communications across networks and it must be solved for secure electronic commerce to flourish. Today, authentication and electronic authenticity are at best only assumptions, and they may prove to be very risky assumptions if not adequately addressed.
As outlined here, security and authentication need to address at least three notions of a secure environment. These include user-to-server authentication, client vs. user authentication, and heterogenous user authentication and access control. Above all, secure authentication services should provide simplified administration from a common point that includes all authentication methods. These services should also allow applications to be developed and extended independent of the authentication technology selected. This will benefit developers, end-users and administrators alike.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.