Novell is now a part of Micro Focus

Understanding the Role of Identification and Authentication in NetWare 4

Articles and Tips: article

RICH LEE
Senior Research Consultant
Novell Research Department

JAY E. ISRAEL
Contributing Editor
NetWare Products Division

01 Oct 1994


This Application Note discusses identification and authentication within the context of NetWare Directory Services and the Trusted NetWare security model. It explains the authentication mechanisms which ensure users are who they say they are when accessing network resources. It also covers the various encryption and decryption methods that are used with authentication, and gives a detailed example of how these technologies work together when a user logs in to a NetWare 4 network.

Previous AppNotes in This Series Apr 94 "Building and Auditing a Trusted Network Environment with NetWare 4" Aug 94 "An Introduction to Novell's Open Security Architecture"

Introduction

Authentication is the process by which a user establishes his or her identity when accessing a network application or service. In the identification phase, the server is informed of a user's identity, after which the server asks for authentication, or proof, that the user is who she says she is. Several identification processes consider a username and password combination to be an effective authentication process.

Unfortunately, most people do not understand the significance surrounding identification and authentication. In this AppNote, we look beyond simple password security and examine how the username/password combination is used to identify and authenticate users, specifically during the NetWare 4 login process.

This AppNote explains some of the underlying mechanisms surrounding initial identification and authentication. Some may argue that a system has greater security when these mechanisms are left unexplained. However, network designers, installers, and integrators need to know how these mechanisms work so they can optimize NetWare's security features, better troubleshoot security problems, and more effectively integrate third-party security solutions. It will also help administrators and users understand what is happening during the login process.

Overview of Identification and Authentication

At first, identification and authentication might appear to be part of the access control component of security- the "who gets to use what" aspect of computers. However, this is not the case. Identification and authentication (often called I&A for short) exist as a separate group of security services, according to the National Computer Security Center document NCSC-TG-028 (the "Orange Book"). The security service groupings identified in the Orange Book are:

  • System architecture

  • Identification and authentication (I&A)

  • Discretionary access control

  • Object reuse

  • Audit

  • System integrity

In NetWare 4, initial client identification and authentication are established with a hosting server during the login process. While the login is performed only once to identify the user desiring access to the server, the authentication process is ongoing throughout the current session to ensure that the service requester is an authorized user. This "background authentication" feature permits authorized transactions with other servers and services.

Password Verification

Before discussing the lower layer ramifications of I&A, we need to talk briefly about the significance of the underlying concept in I&A: password verification.

The password is a device used to prevent one person from masquerading as someone else on the network. It's purpose is to prevent unauthorized access to network resources or data. Users provide a password to a server for the purpose of comparison. The server has a copy of the password and will compare the identified User object's password with the password received from the end-user.

While this concept seems straightforward enough, there is always the threat that someone will try to discover a way to breach password security. Indeed, breaching password security without being detected is the ideal goal for subversive attacks. It allows for numerous methods of subverting network security. Thus the mechanisms involved in protecting the password must be sufficiently strong to foil attacks at the I&A component level of network security.

Password protection mechanisms can be both physical and electronic in nature. Physical password protection may involve not writing passwords down, or picking randomly generated passwords which cannot be easily guessed (see U.S. Government document CSC-STD-002-85 on password security). Electronic password protection may involve mathematical methods for scrambling the password or causing the password to be unreadable by anyone except the server at the time the password is being compared for authenticity.

Yet to employ electronic methods in password protection, one must be aware of the procedure and methods utilized for both transmitting passwords and receiving authenticated status. Even if the password comparison is sufficiently impervious to attack, a weak authentication status mechanism would be vulnerable.

Basic I&A Process

Identification and authentication involve more than just typing the LOGIN command and providing a password to log in. Technically, the basic flow of the I&A process is as follows (up through the point of access control):

  1. Connection

  2. Communication

  3. User identification

  4. User authentication

  5. Access control

The "connection" phase refers to the physical process of gaining access to the network medium. This is followed by the discovery of which server can supply the client with sufficient information about the network, which leads to the eventual communication between client and server on the network.

The NetWare Core Protocols (NCPs) used for logging in to NetWare 4 allow a client and server to create, maintain, and destroy service connections. A service connection forms a logical communication path "over the wire" as the basis for the login between the end-user (client) and the host (server). The client and server will utilize this logical communication path to transmit NCPs which identify the user at the client (workstation) and in server-to-server communications.

At this point, initial contact with the network media has been established and the client and server have created a service connection: a logical, unauthenticated communication path. During the initial phase of communication, it is necessary for the workstation to gain access to specific network objects before authentication restrictions come into play. Specifically, the client needs to get the closest NetWare 4 server's name and address so it can query the NDS database for a User object in the Directory tree that matches the username provided in the LOGIN command.

In NetWare 4, an unconnected workstation client obtains an NDS server address by broadcasting a SAP Get Nearest Server request. Any server or router receiving this request and having knowledge of NDS servers replies with a Get Nearest Server response. By looking at the Service Name field, the client can determine the NDS tree name supported by the server, and use that information to choose which server to contact.

Once this is done, the user identification process can begin. In simplified terms, the client issues a Get Directory Information request to the initial contact server for a user "entry ID" that matches the supplied username. If the requested ID is found in the Directory, the NetWare 4 server sends a Get Directory Information response containing the data necessary to complete the mutual authentication process. (A more detailed description of these requests and responses is given later in this AppNote.)

The important thing for network administrators to remember is that, in NetWare 4, the identification and authentication process happens after a physical connection to the network media is obtained through the client. Thus a certain amount of information must be publicly available prior to logging in. As we have seen, it is currently necessary in NetWare 4 for identification to occur across the physical communication channel "in the open." This also allows other services to occur prior to authentication. For instance, end-users can:

  • Begin the process of personal identification to the network by executing the LOGIN.EXE program

  • Run the CX.EXE command to list the Directory contents (tree name, Organization, Organizational Unit, and so on), determine which part of the Directory tree they are in, and navigate up and down the tree

This provides quite a bit of information prior to LOGIN- information the administrator must be willing to make public to unauthenticated end-users on the network. Of course, further services beyond Directory EXEs and CX are unavailable.

The Concept of a Trusted Path

For the purpose of initial login, the identification process is currently initiated at the workstation in the Application layer (OSI Model) and proceeds down through the lower layers until reaching the workstation's network adapter. From there it goes out across the wire and on to the server, where it travels back up the protocol stack.

As we have seen, the physical identification process (getting the correct physical connection) occurs prior to the login sequence at the physical layer. As a result, a user cannot assume confidentiality at the initiation of login unless some form of encryption is included in the conversation at the physical layer. This suggests that the network media can be a potential source for snooping.

Since this initialization of communication occurs before the client can join the network, the Trusted NetWare security model introduces the concept of a trusted path. In this model, the workstation acquires a trusted path upon which the LOGIN application is built, to provide assurance in a trusted LOGIN execution. This process completely reverses the ordering of importance from untrusted client with an unsecured workstation operating system to a trusted client login with a trusted path.

Supporting Concepts

The preceding overview should have given you a general idea of what I&A is all about in NetWare 4. This section introduces other concepts that are important to understand before we delve into a detailed example of I&A in action.

Transmitting NDS Requests and Replies

The design of NetWare Directory Services builds on previously implemented capabilities of NetWare. These include the network layer infrastructure, IPX (NetWare's native network layer datagram delivery protocol), Service Advertising Protocol (SAP), and NCPs. Because NCP is a request-response protocol, each NDS operation involves an exchange of messages. The client sends an NDS request message; the server responds with an NDS reply. Messages can be of arbitrary size; the actual sizes are communicated as part of the protocol.

Each client NCP request occupies one network-layer packet, as does the corresponding reply from the server. (An exception to this is packet burst, or burst mode, which we don't discuss here.) Since NCP is layered directly on IPX, NDS messages are enveloped within IPX packets, as shown in Figure 1.

Figure 1: NDS data is embedded within the IPX data portion of NetWare packets.

Fragmentation. IPX does not include packet fragmentation/reassembly. This is rarely a problem for NCP since most NCP requests can be "fitted" inside of one IPX packet. As a result, every request or reply packet is limited by the amount of data that can fit in the transmission medium's maximally supported frame size. However, some NDS request and reply messages are lengthy- far more than a single frame can hold. NCP accommodates the need for such large messages by sending all NDS request and reply messages using a fragmentation protocol layered above NCP. Even messages that fit in a single frame are sent using this fragmentation protocol.

Using fragmentation, an NDS request "message" is sent using several NCP request/reply exchanges. Likewise, an NDS reply message can be several NCP request/reply exchanges. Fragments of each request or reply message are sent in order on an NCP session. Fragments of different NDS messages can be interleaved.

The NCP Completion Code in each reply's NCP header reports the server's acceptance (or non-acceptance) of that fragment. Any NCP Completion Code other than "Success" indicates that the NDS request is not processed. The client discontinues activity on that NDS request and reports an error. Other operations using the NCP sessions are not affected, and new messages can begin.

Fragment boundaries within a message need not bear any relationship to the internal structure of the NDS request or reply. Fragment boundaries can be at any convenient spot.

Note: When observing NetWare traffic, remember that certain data-link protocol standards require extra padding bytes after the IPX packet. For example, IEEE 802.3 requires that every frame contain an even number of bytes (with a minimum of 64 bytes). Extra padding bytes are part of the data-link frame, but not part of the IPX packet. Thus the data-link layer indicates one length (including the padding), but the IPX header indicates a shorter length (excluding the padding).

Negotiating Frame Size. Determining the frame size to use is not a trivial issue and typically involves information that the network layer provides to the application. It is safe to use 576 bytes (including the IPX header but not the data-link header with Ethernet), but larger frames often improve performance. If the client and server share a network segment, that segment's largest supported frame size is available. If not, data between client and server is forwarded by routers from segment to segment. The segments can support different frame sizes.

If the internetwork is using the new NetWare Link Services Protocol (NLSP) routing protocol throughout, the end-to-end maximum transmission unit size can be determined from the nearest router. Otherwise, an adaptive method is employed to determine a packet size that is usable for end-to-end communication.

Control Information. There are two kinds of control information involved in transmitting NDS requests and replies. First, there is the fragmentation header used to convey NDS messages. Then, there is the generic format of the multi-fragment NDS message itself.

Figure 2 illustrates an example of a multi-part request and reply. Bear in mind that each fragmentation header is preceded in the packet by the NCP header, the IPX header, and the data-link header.

Notice that while the NDS request is being conveyed, the NCP replies consist only of the fragmentation header. Likewise, while the NDS reply is being conveyed, the NCP request consists only of the fragmentation header. The server sends the first fragment of a reply message in response to the last NCP request of the request message. If both the NDS request and the NDS reply fit in a single packet, only one packet travels in each direction.

Figure 2: NCP uses a higher-layer fragmentation protocol to convey an NDS message exchange.

This fragmentation protocol includes a uniform treatment of error replies across NDS operations. The client detecting an anomalous situation part way through this exchange can interrupt it using a Close Fragmentation request.

NDS Authentication States

Once an NCP service connection is established between a client and a NetWare 4 server, the connection can traverse a succession of authentication states. There are two key concepts:

  • Authentication. A connection is authenticated when the server has verified the user's identity. This can be accomplished using either the NetWare 3 or the NetWare 4 protocol.

  • License Consumption. A connection is licensed when it is consuming one of the user licenses for which the customer has paid. A 100-user server supports up to 100 licensed connections simultaneously. Only authenticated connections can be licensed.

These two state components determine what operations are allowed. For example:

  • When a connection is neither authenticated or licensed, the user can navigate the NDS directory, locate available servers, and initiate a login.

  • When a connection is authenticated but not licensed, the user can access the NDS name space- withpermissions determined by the user's identity-and can access his or her own login script, but cannot access files.

  • When a connection is authenticated and licensed, the user can employ all operations, with permissions determined by the user's identity.

An NCP service connection begins in an unauthenticated, unlicensed state and can go through several state transitions during its lifetime. Figure 3 illustrates the state transitions that occur during a user login.

As Figure 3 indicates, state changes are provoked by certain NCP requests or request sequences. We have seen how NetWare 4 authentication occurs after an initial connection is made to an NDS server. This involves user interaction to supply the username and password. Successful completion of NetWare 4 authentication leaves the user in the Authenticated, Not Licensed state. Once in the Authenticated state, the "User ID" variable is used, as it contains valid information on which access control decisions can be based.

Most network operations require the connection to be licensed. At several points, a procedure call to the server's license manager is made to determine if there are licenses available. The Change Connection State NCP is used to switch between Not Licensed and Licensed. There is no state change if no licenses are available.

Note: While the NetWare 3 login sequence is not specifically covered here, the sequence places the user in the Licensed state when completed successfully.

Background authentication is an ongoing process that occurs whenever the user acts to access resources on additional servers. In this situation, NetWare performs the user authentication in the background, without user involvement.

Figure 3: When a user logs in, the NCP Service Connection undergoes several state changes.

Figure 4 illustrates the state changes that occur when a user logs out. Note that any exit from the Licensed state causes the license manager to be notified, so it can make the license available to others.

Figure 4: When a user logs out, the NCP service connection undergoes a different series of state changes.

As you can see, the authentication mechanism is a primary component of NetWare 4 security. Authentication or the authenticated state is granted to a user only after some particular procedure or mechanism is invoked and completed. Some of the instances requiring the authentication mechanism are listed below:

  • The user and NDS server mutually authenticate each other (this occurs when the user logs into the network).

  • The user and an application service (for example, file service) mutually authenticate each other.

  • A new user is created, which involves establishing his or her initial password.

  • The user changes his or her password, or an administrator changes a user's password.

Each of these instances follow a pattern in which each client/server exchange uses NCP, with the NDS fragmentation, as described earlier in this AppNote.

Note: The authentication mechanism requires the client to read information from NDS. To avoid circularity, the specific corresponding NDS data objects are not subject to access control during login. An unauthenticated user can see objects which the administrator has not specifically occluded from the tree.

Cryptography Concepts in User Authentication

Encryption and decryption technology is an integral part of NetWare 4's authentication services. Many people believe that encryption is an end unto itself- once something is encrypted, all is well. However, there are significant evidences against encryption as a be-all and end-all methodology. This is especially true of application-based encryption, which cannot be classified as a authentication mechanism.

Several products currently offer application-based security where access controls exist within the application (such as password access to files, encryption, and so on). It is becoming clear, however, that no security mechanism without origin in the operating system can or will offer levels of security acceptable to protect information of significant value.

Such a dismissal of application-based security may be hard for some to embrace; to others it may seem insignificant. The C2 security standards address the needs of citizens, commerce, and government, and come with a list of proofs which are undeniable. Operating system based-security is the only real protection available at Class C2. Protecting information of significant value is the basis for Class C2 evaluation for the NetWare server and client.

In round-about fashion, then, we arrive at two conclusions: (1) NetWare 4 should provide authentication security from within the operating system, and (2) those mechanisms should be sufficiently strong as to prevent a security breach.

NetWare 4's authentication processes are directed to attaining both goals above. While we may well be interested in ensuring the identity of a given user, we are particularly interested in not revealing the critical components allowing others to verify or impersonate that user's identity. This is the critical issue surrounding user ID/password combinations.

To perform the act of verification, the user must reveal something unique to the server that only the user could know. Since the server is part of a client-server pair, communication of the password between the client and server is analogous to distant users communicating important messages using paper cups connected with a string.

Using this paper cup analogy, the sender and receiver must first agree upon and privately communicate some secret for verification beyond sight or voice recognition. One party can then re-verify the other's identity by having the other party restate the secret. Unfortunately, the resultant communication relies upon absolute privacy for communicating the secret...a pretty good trick whether you're working with paper cups or with networks.

In either case, if someone else is present when the secret is sent across from one location to the other, the secret only be safe for the first communication. The validity of reusing the secret comes into question the second time, since anyone who was listening and heard the secret can impersonate the sender by replaying the secret. The confidentiality of the secret (password) cannot be maintained by simply encoding it. An imposter could simply imitate the coded communication, which would compare successfully with the coded secret.

In light of difficulties such as scrambled password comparisons and potentially dubious storage techniques for information verifications, NetWare 4 needed better methods for both verifying user identity without revealing passwords and for concealing private information which cannot be easily reproduced. To overcome some of these difficulties, Novell employs several cryptographic methods to conceal information. Once concealed, the information can then be left in plain sight, if necessary.

One implementation makes use of cryptographic ciphers. Ciphers are different from codes and go beyond the techniques of simple substitution to render information unclear. Ciphers utilize a changing basis for computing output and are difficult (even practically impossible) to substitute in a masquerade attack.

The basic operations in cryptographic ciphering are encryption and decryption. NetWare incorporates both of these into the NetWare 4 authentication mechanism, along with other procedures to ensure the confidentiality of the end-user's authentication data.

Secret Key Encryption. To introduce ciphering techniques, we present an example of classical encryption. In classical encryption, messages are protected from eavesdropping (being viewed by others) by the use of a methodical transformation. In classical encryption, this is a mathematical transformation utilizing a parameter known as an encryption key. The key is known to both sender and receiver, but is kept secret from all others. This type of encryption is called secret key encryption, and is illustrated in Figure 5.

Figure 5: In secret key encryption, the key is kept secret from everyone but the sender and receiver.

The original message is called clear text (or sometimes "plain" text). The encryption step transforms the plain text into cipher text: a concealed form unintelligible to an eavesdropper.

The secret key is used in the encryption algorithm, and is also used by the decryption algorithm which reverses the transformation. The decryption process recovers the original clear text message for the intended recipient.

One of the difficulties with classical encryption technologies is that the secret key must be retained by both users for each sender-receiver pair involved. This makes secret key encryption impractical in large internetworks because of the thousands of potential sender-receiver pairs requiring keys and the difficulties of distributing private keys. It is too burdensome for users to keep track of all the keys for everyone they might contact. Since each pair of correspondents needs a separate key, having n users requires on the order of n2 keys. This realization led to the advent of public key encryption.

Public Key Encryption. In public key encryption, there are two keys instead of just one as in secret key encryption. The encryption key is different from the decryption key, and they form what is known as an asymmetric pair (explained later). The innovation is that the encryption key does not have to be kept secret. The encryption key is termed "public" because it can be distributed openly to anybody caring to send a message to the holder of the key.

If user A wants to send an encrypted message to user B, it is only necessary to have user B's public key. In other words, user A employs user B's public key to encrypt the message. The decryption process uses a private key, kept secret by user B. Figure 6 illustrates public key encryption.

Figure 6: In public key encryption, the encryption key is public and the decryption key is private.

While the clear text message can be encrypted by the recipient's public key, only the recipient's private key can decrypt the message. Neither key will work for decryption if that key was used to encrypt the message. In other words, once a message is encrypted with the public key, the same public key cannot decrypt it. This is why the process is known as asymmetric. Additionally, the two keys are related mathematically in a way that makes the encryption reversible, but the private key cannot be derived from the public key in any practical way.

Public keys have an advantage over secret keys in that public keys can be distributed "in the open"- that is, on an internetwork, users' public keys can be kept in a widely accessible on-line database. When A wants to send B a message, A can obtain B's public key from the database. This is much easier than implementing methods for secret key exchange, which cannot be done in the open by itself.

How NDS Uses Encryption

At this point you might be asking what all this has to do with NDS - after all, NDS is not a system for sending encrypted messages between users. The answer is that NDS uses encryption for authentication. We have already discussed how NetWare 4 features both initial login authentication and ongoing background authentication.

Authentication services use encryption to protect their exchanges. Both public-key and private-key designs exist. Figure 7 shows how an authentication service operates. User accounts are maintained at authentication servers, and are often replicated on a large network. When a user wants to access an application service, messages are exchanged between the client computer, the application server, and an authentication server.

Figure 7: Authentication service.

NDS acts as an authentication service. With NDS authentication, the client computer first logs into an NDS server to establish the user's identity. Having done this, it can then do background authentication to set up a connection with another service. NetWare client software does background authentication behind the scenes, without user involvement.

NDS uses encryption to protect the authentication messages. Encryption is useful not only to conceal messages, but also to validate identity. Correctly sending a message encrypted a certain way is evidence that the sender knows the corresponding encryption key.

Nonce Values. To prevent an intruder from capturing and replaying authentication messages, these exchanges use nonce values extensively. A "nonce" is a random value coined and used only once. For example, A can test B's identity by encrypting a nonce value with B's public key, sending the cipher text to B, and having B reply with the nonce in plain text. By successfully decrypting the nonce, B exhibits knowledge of the private key. If an intruder wants to impersonate B, it does not help to capture the exchange to use later, because next time the nonce will be different.

Message Digest Functions. A message digest (one-way hash) function is another computation useful in authentication. It is an irreversible operation on a message, used (for example) to verify that the sender holds certain information without sending the information itself (either in plain text or cipher text).

A message digest function, H(M), operates on an arbitrary-length message, M, producing a small fixed-length hash value, h = H(M), with the following characteristics:

  • Given M, it is easy to compute h.

  • Given h, it is hard to compute M.

  • Given M, it is hard to find another message N withH(M)=H(N).

Encryption Methods. NDS uses both public key and secret key encryption in the course of authentication. It also uses message digest functions. Below is a list of encryption methods used in the design of NDS. The following detailed example specifies how these methods work together in NDS during login authentication.

  • RSA is a public key method. The acronym represents the initials of its three inventors. RSA security hinges on the difficulty of factoring large numbers.

  • RC2 is a secret key method designed for security and computational speed.

  • Between the client and the application server, NDS uses a variant of the Guillou-Quisquater (GQ) "zero knowledge" proof-of-identity method. It is called zero knowledge because the application server learns nothing from the client that could not be learned independently.

  • MD2 and MD5 are message digest algorithms documented in RFC 1319 and RFC 1321, respectively.

Novell's NDS implementation incorporates the BSAFE encryption software library version 1.7 from RSA Data Security, Inc. in Redwood City, CA.

Example: Authenticating a User at Login

The following example goes into more detail to show how an initial user login takes place using NetWare 4 authentication. This discussion assumes that an NCP session already exists, and that session negotiations (for example, establishing a maximum packet size) are complete.

Before starting authentication, the client uses SAP to locate the nearest NDS server having the same tree name as the user.

The exchange between the client and the NDS server is illustrated in Figure 8. Note that the use of nonce values for random numbers blunts a replay attack.

Figure 8: This example details the keys and messages exchanged during a NetWare 4 initial user login.

Initial Information

Initially, the client computer has:

  • The user's Distinguished Name

  • The user's password

Initially, NDS has in its repository:

  • The user's Distinguished Name

  • A Salt value for the user (an object-specific random number used to blunt a dictionary attack during Login)

  • A hash based on Salt and the user's password:

    HSP = Hash1(Salt, password)

  • The user's public RSA key

  • An encrypted value of the user's private RSA key, with HSP as the encryption key

Steps A-B

In Steps A and B, the client identifies an operational server which holds a writable replica of the NDS entry describing the user.

Note: A writable replica is required because the act of logging in updates object information in the NDS database (for example, the Last Login Time attribute of the NDS object describing the user).

Specifically, the exchange in Steps A and B supplies the user with two pieces of information:

  • The identity of an NDS server holding a writable replica of the user's NDS object.

  • A User ID, in the form of an NDS Entry ID which is valid on the server holding that replica.

Step A uses the NDS Resolve Name operation. This request can be sent to any NDS server in the same tree as the user's NDS object. However, the remaining steps are carried out between the client and the server identified in Step B. If necessary, the client opens a new NCP session to that server.

Having completed Steps A and B, the client has the information needed for mutual authentication based on private knowledge. The main ingredient of the private knowledge is HSP, which contains the hashed password and is already stored at the server.

Steps C-D

The exchange in Steps C and D use the Begin Login operation. The server checks the User's Entry ID to verify that it refers to a writable entry. The Begin Login reply (step D) includes the following information:

  • The Salt value stored in NDS with the user's private key.

  • A random number, R1, used as a challenge in the subsequent steps.

Step E

The computations in Step E prepare for the crucial exchange in Steps F through H. While HSP is stored at the server, it is not sent on the wire. It must be computed at the client, based on (1) the password typed in by the user, and (2) the Salt value obtained in Step D. We refer to this computation as Hash1.

In the next part of Step E, the client uses the Hash2 function to compute Y. This hash function uses the RC2 encryption algorithm. The value HSP (described above) is the RC2 key. The challenge R1 is the plain text being encrypted by RC2. The computed cipher text is the Hash2 value.

To conclude Step E, the client chooses:

  • A random number, R2. This value is used as a challenge to validate the server.

  • A large block of random data, S, which the server will use to help conceal the transmission of the user's private key to the client.

The user will need the server's public RSA key for Step F. This is obtained by querying NDS before Step F and reading the Public RSA Key attribute of the server object. It is important to note that any unauthenticated client has access to the Public RSA key attribute.

The client also needs the user object's official basic Distinguished Name (not an alias) for constructing the Credential. It uses the Read Entry Info operation to obtain this value.

Steps F-H

The exchange in Steps F through H uses the Finish Login operation.

In Step F, three values are encrypted using the server's public key. Because public key computations are computationally intense compared with secret key methods, NDS uses a common technique to transmit a long message efficiently and securely:

  1. Generate a random nonce key NK.

  2. Encrypt NK by public key (RSA) encryption, obtaining cipher-text CT1.

  3. Encrypt the message by secret key (RC2) encryption using NK, obtaining cipher text CT2.

  4. Transmit both CT1 and CT2.

  5. The recipient decodes CT1 to obtain NK, then uses NK to decrypt CT2 and obtain the message.

CT1 and CT2 appear in the Finish Login request.

In Step G, the server checks that the client has the actual user password. Without this knowledge, Hash2(HSP, R) could not have been computed; nor (by implication) could Y.

Note: Checking this before conveying the user's private key blunts a password-guessing attack. Without this check, an intruder could try passwords from a dictionary one after another until R2 in Step H matches the value chosen in Step E. At that point, the user's private key would be exposed.

In Step H, the server retrieves the Key Data value from the Private RSA Key attribute of the user's NDS entry. This is an encrypted value of the actual private key, using HSP as the key to encrypt the key. These bytes are then exclusive ORed with the bytes of the decrypted S field received in the Finish Login request. The mathematical symbol "q" in Step H represents the bit-wise exclusive OR operation. Any extra bytes of S are disregarded.

The three-part "plain text" in the Finish Login reply is then assembled. The plain text is encrypted using RC2, with Y (the value from step E) as the encryption key. This becomes the Reply Cipher Text Data in the Finish Login reply.

By decrypting the message H, the client obtains the encrypted value of the user's private key (encrypted using HSP). Since Step E provided HSP, it can now derive the user's private key. The client also obtains R2 and checks it, to verify that the server is genuine- only the server could have decrypted message F to learn R2.

Discontinuing the Exchange

At any point the server decides to discontinue the exchange, it replies with an NDS Completion Code indicating the reason. The authentication exchange halts, but the client can continue to use the NCP connection for other request messages. For intruder detection, the server counts the number of mismatches at Step G, and locks the user's account when there are too many within a specific time interval.

The client can decide to discontinue the exchange after Step B or D by simply going on to something else on the NCP session, or by closing the session.

Authentication and the Trusted NetWare Model

When discussing I&A in NetWare, it is important to note that other versions of NetWare do not provide the authentication security derived from the NDS verbs in the operating system. The NetWare 4 approach is not currently available in previous versions of the operating system, and will therefore show lower assurance levels for I&A with regard to current versions. This may be one of the more significant ramifications of NetWare 4 I&A, since other systems (including those outside of NetWare) may find it advantageous to use NetWare 4's authentication services.

With other versions of NetWare and other systems trying to obtain access to the NetWare 4 server, it becomes clear there will be at least two security levels for clients trying to access the trusted server: untrusted clients and trusted clients. The major differences between these two levels lies in the degree of assurance attributable to the workstation client. Certainly there will be networks where the administrator desires a secure environment, and there will be others where untrusted clients will be attached to trusted servers.

It is essential to recognize there is always valuable information being stored on the network. Sometimes this information is at the server; sometimes it is present at the client. Whenever valuable information (such as unprotected passwords) exists at an unsecured client, there is the possibility of having it compromised. Network security administrators essentially playing the odds of compromise with lower levels of assurance at the client or at the server.

Having a secure network means replacing obscure security with clearly implementable and well-defined methods for obtaining assurance. Administrators seeking the highest levels of security will settle for nothing less than physically controlled environments utilizing trusted servers and clients. Physical controls such as mandatory access and physical isolation of components do provide security assurance, but they may reduce useable features below minimum user expectations.

Where the features and functionality of network software do not allow for physical containment, Trusted NetWare servers and clients will offer a level of assurance compatible with Class C2 evaluation. For assurance, Class C2 offers the administrator flexibility in combining trusted and untrusted clients on the network. Class C2 security produces a level of assurance that is commensurate with logical protection and provides a viable alternative to strictly physical security.

Summary

NetWare 4 security is based upon Novell's open security architecture. NetWare 4's I&A security is based upon the Class C2 evaluation of the logical protection mechanisms inside the next release of NetWare 4. These include Novell's implementation of the GQ zero knowledge proof and the utilization of RSA and secret-key encryption schemes. These mechanisms are being used to ensure the confidentiality of user I&A information in NDS and during login.

In NetWare 4, I&A is based on the use of NDS verbs that are an integral part of the operating system. NDS is an inherent part of I&A security and provides a mutual authentication scheme. NDS is responsible for replicating and updating user keys in the I&A schema, as well as for background authentication with other servers and services on the network.

Encryption in NetWare 4 is based upon programmatic routines taken from the RSA BSAFE cryptographic library, and upon the GQ zero knowledge proof-of-identity scheme. While RSA is the primary form of encryption, other encryption methodologies can be developed to operate under the NetWare 4 open security architecture.

* 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.

© Copyright Micro Focus or one of its affiliates