NMAS: It's What Spy Movies Are Made of
Articles and Tips: article
01 Feb 2000
Have you seen the 1997 movie "Mission: Impossible"? If you have, you undoubtedly remember the scene where Ethan Hunt (the hero Tom Cruise portrays) lowers himself from a vent and downloads top-secret information while suspended above a pressure-sensitive floor. When you were watching Hollywood's depiction of life, you probably cheered for Hunt. But in your real life, you'd be more likely to cheer for the IT team responsible for securing the information Hunt is trying to steal. Why? Because you're a network administrator and protecting information is part of your job.
Granted, if you're like most network administrators, you're probably not tasked with protecting over-the-top secret information that spy movies are made of. Nevertheless, your company almost certainly has information that it wants to keep private--whether that information is government or military secrets, student or patient records, bank accounts, research files, or something as mundane as payroll data.
How do you protect this information? For starters, you probably require users to authenticate to the network, thereby ensuring that only authorized users can access network information. More specifically, you probably require users to enter Novell Directory Services (NDS) passwords to authenticate to the network. "NDS password authentication technology," says Buck Gashler, Novell product manager, "is very secure." However, Gashler concedes, "it is a password authentication scheme, and there are certain security issues with passwords."
You probably know about the security issues Gashler is referring to. No matter how many times you talk to users about creating secure passwords, enforcing your guidelines is difficult at best. How can you guarantee that not one user chooses an anniversary date or a dog's name as a password? How can you ensure that not one user writes a password on a Post-it note and sticks it under the keyboard or in a day planner? As you know only too well, you can't. Consequently, it doesn't take a spy to crack a password; it just takes one careless or indifferent user.
WHAT YOU KNOW, WHAT YOU HAVE, AND WHO YOU ARE--NDS WANTS TO KNOW
Of course, passwords are not the only secrets that users can enter to log in to a network. Passwords are an example of only one of three categories of such secrets, called login factors. The three categories of login factors are as follows:
Something you know, such as a password
Something you have, such as a token, public-key certificate, or smart card
Something you are, that is, your face, fingerprint, or voice
Login methods incorporate one or more login factors from one or more of these categories. Each specific login method has unique strengths and weaknesses, and the question of which method is the most secure is highly debatable and perhaps the wrong question. (For more information about the relative strength of different login methods, see "My Way's Stronger Than Your Way!")
Recognizing the security issues associated with passwords, many of you have considered using alternate login methods based on factors from the something-you-have or something-you-are categories. Some of you have even considered combining login methods from different vendors that together would require factors from two or three of these categories. Although you have considered these possibilities, most of you are still using NDS password authentication alone. Why? There are at least two probable reasons:
Until recently, the password authentication scheme was the only scheme that NDS natively supported.
You think that finding alternate NDS authentication schemes will take more time (and money) than you can spare.
During the last century, you may have been right. But during the first quarter of the 21st century, Novell will prove you wrong with Novell Modular Authentication Service (NMAS, pronounced en-mass) 1.0. With the NMAS client-server software and its ConsoleOne snap-in module, you can authenticate users to NDS by deploying login methods based on any type of login factor or based on a combination of factors.
SPY-STUPEFYING AUTHENTICATION
NMAS supports these login methods through several authentication modules that Novell and third-party vendors provide. In this first release, the Novell-developed authentication modules support users logging in with an NDS password or with an X.509 v3 certificate, such as those you can mint and manage using Novell Certificate Server 2.0.1.
Novell Certificate Server 2.0.1 is public key infrastructure (PKI) software that enables you to create, manage, and store public-key certificates (in the industry-standard X.509 v3 format) and their associated private keys. With Novell Certificate Server 2.0.1, you can create within an NDS tree a Certificate Authority (CA) that is unique to your company. You can then have this internal CA sign the server and user certificates you generate. Alternately, you can send certificate-signing requests to an external CA, such as VeriSign. (Novell Certificate Server 2.0.1 is included on the NMAS Enterprise Edition CD and is also available free on Novell's web site at http://www.novell.com/download/#NDS. For more information about Novell Certificate Server 2.0, see "Novell Certificate Server 2.0: Is Your Network Certifiably Secure?" NetWare Connection, Jan. 2000, pp. 6-20. You can download this article from http://www.nwconnection.com/past.)
Novell Certificate Server 2.0 stores signed user certificates in an NDS User object attribute called userCertificate. Before using certificates to authenticate to an NMAS-enabled network, users must first export their certificates and the associated private keys from NDS. Users can then download their certificates to a floppy diskette, a local hard drive, or even a smart card and thereafter use the certificate to authenticate to NDS via NMAS. (Smart cards are cards with computer chips that may contain a CPU and memory.)
In addition to the Novell-developed authentication modules, NMAS includes the following modules:
ActivCard Module for NMAS from ActivCard Inc.
Identicator BioLogon Module for NMAS from Identicator Technology (a division of Identix)
RSA ACE/Agent for NMAS from RSA Security Inc.
Secure Authentication Facility (SAF) Module for NMAS from SAFLINK Corp.
VASCO Digipass Module for NMAS from VASCO Data Security Inc.
The specific login methods these modules enable rely on a broad range of login factors, enabling authentication based on tokens, smart cards, fingerprints, voices, or faces. To deploy the methods these modules enable, you may need to purchase additional hardware or software. (For more information, see "Login Methods Worthy of Bond, James Bond.")
As more third-party vendors write NMAS authentication modules to enable their login methods to operate in an NMAS environment, you will have the option to install the associated software. Naturally, new NMAS authentication modules will be available from the vendors who develop them. In addition, Novell may make some of these new modules available for download on its web site.
ONE LITTLE, TWO LITTLE, THREE LITTLE METHODS
With this arsenal of authentication modules, NMAS enables you to create one or more company-wide authentication policies, each of which indicates a login sequence you will require for NDS authentication. These login sequences may include one or more of the login methods NMAS supports, depending on which version of NMAS you are running--NMAS Starter Pack or NMAS Enterprise Edition.
NMAS Starter Pack has been available as a free download on Novell's web site since January 17, 2000. (You can download NMAS Starter Pack by visiting http://www.novell.com/download and clicking "NDS.") Novell also plans to bundle NMAS Starter Pack with other Novell products. Using NMAS Starter Pack, you can create one or more login sequences, each of which can be based on any one (but only one) of the login methods enabled by the NMAS authentication modules.
For example, you can create a login sequence based on the Identicator BioLogon Module for NMAS, which provides a fingerprint-recognition login method. Using a login sequence based on Identicator's method, users log in by placing their finger on a scanning device. (For more information about this and other login methods NMAS supports, see "Login Methods Worthy of Bond, James Bond.")
You could also deploy a login sequence based on a two-factor login method. For example, you could create a login sequence based on RSA Security's RSA ACE/Agent for NMAS. RSA ACE/Agent for NMAS is a two-factor login method that requires users to enter both a Personal Identification Number (PIN) and either a token or a smart card. The modules from ActivCard and VASCO also enable two-factor login methods.
Regardless of the specific login method you deploy and whether that method is a single-factor or multifactor login method, users who successfully complete a login sequence are authenticated to NDS. Beyond this first layer of security, you then control users' access to information on your company's network in the same way you do now, that is, through Access Control Lists (ACLs).
In other words, with NMAS Starter Pack, you are no longer limited to deploying only password-based login methods for all of your users. With NMAS Starter Pack, you can deploy different login methods for different users. You can also deploy multifactor login methods. However, with NMAS Starter Pack, you cannot combine login methods (that are enabled by different NMAS authentication modules). Also, with NMAS Starter Pack alone, you cannot control users' access to information based on the login sequence they use to authenticate to NDS. For these capabilities, you need NMAS Enterprise Edition, which will be available for purchase beginning in March 2000.
GRADED AUTHENTICATION: HOW DID YOU GET HERE?
As with NMAS Starter Pack, NMAS Enterprise Edition enables you to create one or more authentication policies that determine the login sequences you will require for NDS authentication. However, unlike NMAS Starter Pack, which allows you to use only one login method per login sequence, NMAS Enterprise Edition enables you to combine an unlimited number of login methods for each login sequence.
For example, you could create a log-in sequence that combines the login methods enabled by one of the Novell modules, by the ActivCard Module, and by the Identicator BioLogon Module. This login sequence might then require users to enter an NDS password, a PIN, a smart card, and a fingerprint to be authenticated.
Although enabling you to combine login methods is exciting, it is not the most exciting feature NMAS Enterprise Edition offers. What is arguably more exciting is that NMAS Enterprise Edition is the first product to take advantage of the graded authentication feature that was first included with NetWare 5.
The graded authentication feature tightens security through a combination of three different means:
Grades
Security labels
Clearance levels
When NMAS authentication modules are developed, Novell assigns each module a grade. In NMAS 1.0, this grade is based on the login factor or factors that a method uses. The grades for authentication modules included in NMAS 1.0 are as follows:
Biometric&Password&Token
Biometric&Password
Biometric&Token
Password&Token
Biometric
Password
Token
NMAS then enables you to assign security labels to NDS partitions and NetWare volumes. The security labels, with one exception, are the same as the grades listed above. The exception is the Logged In security label.
The Logged In security label enables access without requiring the use of a specific login method. All users who have attached (but not authenticated to the network) will gain read-only rights to any partition and volume labeled Logged In. (Of course, access to NetWare volumes is still controlled through the ACLs for those volumes.) Because all NDS partitions and NetWare volumes have the Logged In label by default, you only have to label the partitions and volumes to which you want to restrict access.
The security labels you assign to particular partitions and volumes correspond to the grade of the login method you require to enable access to these partitions and volumes. For example, you can assign a Biometric&Token label to an NDS partition and NetWare volume and subsequently create a login sequence that incorporates a login method with a Biometric&Token grade. You can also create a login sequence that incorporates a login method with a Biometric grade and another method with a Token grade, so that the combined grade is equal to the Biometric&Token security label.
CLEAR TO GO
The whole point of assigning security labels to volumes and partitions is to enable you to increase security for parts of the network that contain sensitive information. However, labels alone will not suffice. To enforce the labels, you must also assign NDS User objects one or more clearance levels.
The names of the clearance levels you assign are identical to the names of the security labels you assign (as well as the grades Novell assigns the NMAS authentication modules). That is, you can assign User objects clearance levels such as Biometric&Password&Token, Biometric&Password, Biometric&Token, and so on. In addition, you can assign a Multilevel Administration clearance. Because users with Multilevel Administration clearance have read-write access to all areas on the network, you should assign this clearance level to only a few users.
When you assign a user a particular clearance level, the user gains read-write access to the partitions and volumes with security labels that match the user's clearance if the following are true:
The user requests that clearance at login time.
The user uses a method with a grade that matches his clearance level. (See Figure 1.)
Figure 1: The level of access a user gains is based on his or her clearance and on the security label assigned to the partition and volume the user is attempting to access.
For example, suppose a user is granted Biometric&Token clearance, requests that clearance at login, and uses a login method with a Biometric&Token grade. This user gains read-write access to partitions and volumes that have Biometric&Token labels. (See Figure 2.)
Figure 2: If you assign a user Biometric & Token clearance and the user requests that clearance for a particular session, the user gains the following access for this session: read-write access to the volumes with a Biometric & Token label, read-only access to volumes with a Biometric label, a Token label, or a Logged In label, and no access to volumes with labels that have more or different login factors than the login factors in the user?s clearance label.
Users do not gain access to partitions or volumes with security labels that include login factors that are not part of their clearance level. (See Figure 1.) For example, a user with Biometric&Token clearance cannot access volumes and partitions that are labeled Biometric&Password&Token. In addition, this user cannot access volumes and partitions that are labeled Password. (See Figure 2.) Users cannot access areas with security labels that are higher than or entirely different from their clearance level.
In addition, users gain read-only access to partitions and volumes with labels that require fewer but at least one of the factors named in their clearance level. (See Figure 1.) For example, if a user is granted Biometric&Token clearance and requests this clearance at login, this user gains read-only access to partitions and volumes labeled Biometric and partitions and volumes labeled Token. (See Figure 2.)
If you are wondering why a user with Biometric&Token clearance doesn't automatically get read-write access to volumes and partitions labeled Biometric and volumes and partitions labeled Token, consider this: The more factor types you include in a login sequence, the more secure the authentication scheme.
Therefore, you will probably label partitions and volumes that hold the most confidential information with security labels that combine two or three types of login factors. You must then ensure that users with read-write access to such partitions and volumes don't accidentally write confidential information to a volume that is less secure. To protect confidential information, NMAS grants read-only access to volumes and partitions that have labels that include the same but fewer factors than those included in users' clearance levels.
As Dan Fritch, Novell development manager, explains, NMAS' use of the graded authentication feature enables you, in essence, "to dynamically mount and dismount volumes and to change the mounting of the volume to read-only for a particular user session. So depending on how a user logs in," Fritch continues, "volumes are mounted as read-write or read-only instead of being globally read-write or read-only for all users in all sessions." In other words, with NMAS and graded authentication, you can essentially mount and dismount volumes and grant read-write or read-only access on a session-by-session basis.
MAKING THE GRADE
To run either NMAS Starter Pack or NMAS Enterprise Edition, you need a server running NetWare 5 with Support Pack 3 or above. (To download the latest support pack, visit http://support.novell.com/misc/patlst.htm#nw.) You will also need NDS 8 and Novell International Cryptographic Infrastructure (NICI) 1.5, which is included with NMAS. NICI 1.5 provides all of the cryptographic services that NMAS (and other Novell security products) requires. (For more information about NICI, see "With NICI It's All Holes Barred," NetWare Connection, Dec. 1998, pp. 8-20. You can download this article from http://www.nwconnection.com/past.)
To configure NMAS Starter Pack or NMAS Enterprise Edition, you need ConsoleOne 1.2, which is also included with NMAS. To enable NMAS login methods (for both NMAS Starter Pack and NMAS Enterprise Edition) and to set up graded authentication (for NMAS Enterprise Edition), you use the NMAS ConsoleOne snap-in module to complete a handful of tasks. Specifically, you need to complete the first four steps listed below to configure NMAS Starter Pack, and you must complete all six steps to configure NMAS Enterprise Edition:
Create a Login Method container object.
Create a Login Policy container object.
Create a Login Method object.
Create a login sequence.
Apply graded authentication labels to Volume objects and partitions.
Apply graded authentication labels to User objects.
When you install NMAS, the Login Method container object is automatically created within the Security container object in the NDS tree. Within this Login Method container object, you create Login Method objects, one for each Novell and third-party method that you plan to use on the network.
The Login Policy container object is also automatically created in the Security container object when you install NMAS. Within this Login Policy container object, you create one or more login sequences, which are stored as properties of the Login Policy container object.
Generally speaking, you should create at least one login sequence for each clearance level you assign. For example, if you assign Biometric&Password&Token, Biometric&Token, and Token clearance levels, you need to create at least three login sequences: One that includes methods graded Biometric, Password, and Token, another that includes methods graded Biometric and Token, and another that includes a method graded Token. However, if you also assigned a Password clearance, you would not necessarily need to create another login sequence because NMAS provides by default a sequence that includes Novell's password method.
You also may or may not need to create a separate login sequence for Multilevel Administration clearance. The sequence that users with Multilevel Administration clearance use must incorporate methods with grades that match the grades of all the methods in use on the network. However, this sequence does not have to incorporate all of the methods in use on the network.
For example, suppose you have some users with Password clearance logging in using a method graded Password. Further suppose that you have other users with Biometric clearance logging in using a method graded Biometric. In this case, you would need to create a separate login sequence for users with Multilevel Administration clearance. The new sequence would incorporate methods graded Biometric&Password but would not necessarily incorporate the same vendor-specific methods that other users are using.
To create a login sequence, you select New Login Sequence from the list of Properties for the Login Policy container object. The Login Sequence tab on the Properties of Login Policy screen shows two main fields: Available Methods (on left) and Login Sequence (on right). (See Figure 3.)
Figure 3: To create a Login Sequence, you click a method listed in the Available Methods field and then click the right-pointing arrow to add it to the Login Sequence field. You complete these steps for each method you want to include in a particular login sequence.
The Available Methods field lists all of the methods for which you have created a Login Method object. To create a login sequence, you give the sequence a name, click the method in the Available Methods list you want to include in the login sequence, and then click the right-pointing arrow to add that method to the Login Sequence field. If you want to add more than one method, you repeat this process. Before you quit the screen, make sure that the methods are in the order you want users to follow.
Finally, you enable graded authentication by completing the following steps: You assign security labels to the NDS partitions and NetWare volumes that hold information you want to protect, and you assign clearance levels to the User objects that need access to those volumes and partitions. (See Figure 4.)
Figure 4: To use NetWare 5?s graded authentication feature, you must assign security labels to NDS partitions and NetWare volumes based on the login factors you will require users to enter to gain access. You must then assign clearance to User objects so that users? clearance matches the security labels on the volumes and partitions to which users need read-write access.
PUT IT ALL TOGETHER, AND WHAT DO YOU GET? ADDED SECURITY
Now that you understand basically how NMAS works, you may be trying to imagine how you can use it to tighten security on your company's network. Suppose you want to protect payroll data using NMAS and graded authentication. Further suppose that you want to grant only users in Human Resources access to payroll data. These users, you decide, will use one method graded Biometric and another method graded Token to authenticate to NDS and to gain read-write access to payroll data.
Assume for this example that you have already installed NMAS and that payroll data is already on a separate NetWare volume. After creating one Login Method object for the Biometric method and one Login Method object for the Token method, you create a login sequence in the Login Policy container object.
As with every login sequence, you assign a name. In this case, let's say you name the login sequence Payroll. To create the Payroll login sequence, you move the Biometric and Token methods listed in the Available Methods field to the Login Sequence field.
Finally, you apply graded authentication. To do so, you assign the Biometric&Token label to the volume and partition that hold the payroll data. You then grant Biometric&Token clearance to the User objects associated with the users in Human Resources.
Now suppose that Leslie in Human Resources is logging in to the network for the first time or that she is requesting Biometric&Token clearance for the first time. On the initial login screen, Leslie enters her username and then selects the Advanced button. (See Figure 5.)
Figure 5: When users log in to an NMAS-protected network for the first time, they enter their username and press the Advanced button on the initial login screen.
When Leslie clicks the Advanced button, two additional fields appear: Login and Clearance. In the Login field, Leslie enters the name of the login sequence she will use, in this case Payroll. In the Clearance field, Leslie enters the clearance level she is requesting, in this case Biometric&Token. Both of these fields have browse buttons that enable users to choose from a list of available login sequences or clearance levels.
When Leslie clicks OK--assuming she has entered the correct information and that you have assigned her the clearance she has requested--she is authenticated to NDS and gains read-write access to the volume and partition that hold the payroll data (assuming her ACLs also grant this level of access). She also gains read-only access to all NDS partitions and volumes with Logged In, Token (only), and Biometric (only) labels (again assuming her ACLs concur).
Leslie must complete these fields only the first time she logs in or each time she requests a login sequence and clearance level that differs from the login sequence and clearance level she requested last. Otherwise, Leslie enters only her username and Enter, after which the login sequence and clearance level she last entered are invoked.
NMAS UNDER COVER
You now know what a user such as Leslie sees when logging in, but what goes on behind the scenes? That is, what happens technically when a user with an NMAS-enabled client attempts to authenticate to NDS?
After Leslie enters her username and completes both the Login Sequence and Clearance fields on the initial login screen, the NMAS client stores these values in the Windows registry. When Leslie clicks OK, the regular Novell client invokes the NMAS client.
The NMAS client searches the network to find which servers hold copies of Leslie's User object. When the NMAS client finds these servers, it asks each one "Are you an NMAS server?" and establishes a connection with the server that responds with "Yes." (If more than one NMAS server holds a copy of Leslie's User object, the NMAS client randomly selects one server.)
To establish this session, the NMAS client and server exchange a session key generated by NICI. This session key enables the NMAS client and server to create a secure pipe over which they can exchange encrypted authentication information.
The NMAS client next sends a message to the NMAS server. This message indicates all of the login methods that have been installed on this client. Novell assigns numbers to each of the login methods enabled by Novell and third-party authentication modules. For example, suppose that Leslie's NMAS client has methods 5, 6, 7, and 8 installed, but Leslie is attempting to use methods 5 and 7. The message from the client indicates that Leslie's client can do methods 5, 6, 7, and 8. This message also indicates that the login sequence Leslie requested requires method 5 be completed and then method 7.
Upon receiving this message, the NMAS server invokes the Login Server Method (LSM) associated with method 5 and then sends a message to the client to DO 5 (in other words, invoke the biometric method). The LSM is the executable code for a particular Novell or third-party authentication module. This code is stored as a property of a Login Method object.
In this case, Leslie is supposed to enter a biometric factor first, so the NMAS server invokes the biometric LSM, and the server starts running the appropriate code. When the NMAS server returns a message to the client that says DO 5, the NMAS client loads the appropriate Login Client Method (LCM), which invokes its own Dynamic Link Library (DLL).
The LSM and LCM then use a protocol called Multi-Authentication Framework (MAF) to exchange the Novell or third-party method information. Novell developed MAF and has submitted an Internet-Draft titled "Multi-Authentication Framework Method for SOCKS v5" describing MAF to the Internet Engineering Task Force (IETF).
NMAS is not privy to the information that the LSM and LCM exchange via MAF. In fact, "NMAS doesn't know what the LSM and LCM are exchanging," says Hal Henderson, Novell software engineer, "and it doesn't care."
During this process, the LCM invokes the method-specific user interface that requests the necessary login factors. In this case, the user interface may request that Leslie press her thumb on the fingerprint-scanning device to acquire Leslie's fingerprint as the biometric factor used in this login method.
The LCM forwards the information Leslie enters to the LSM. The LSM compares the information it receives with the information stored in NDS to ensure that the user has entered the correct information. If Leslie really is Leslie and her biometric factor is legitimate, the LSM returns a message to the LCM, indicating this portion of the login sequence is done and successful. Both the LSM and LCM then return to NMAS.
If Leslie enters incorrect information, the NMAS server sends a message to the LCM, indicating that this portion of the login sequence is finished but unsuccessful. Leslie sees a window, indicating that her login failed. The initial login screen then appears, and Leslie can try to log in again.
When one login method is completed, the NMAS server confirms whether it has all of the information needed to authenticate Leslie or whether more information is required. In this case, Leslie must still use a token method to complete her login sequence. Consequently, the NMAS server invokes the LSM for method 7 and sends a DO 7 message to the NMAS client. The client responds by invoking the LCM for method 7, in other words, invoking the token method Leslie must complete. This process continues until the NMAS server is satisfied that it has received all of the information necessary to authenticate Leslie to NDS.
When the NMAS server is satisfied that it has received all of the information necessary to authenticate Leslie to NDS, this NMAS server returns a message to the NMAS client indicating this. The NMAS client then asks the NMAS server for Leslie's NDS credentials. The NMAS server retrieves and returns to the NMAS client Leslie's credentials, which essentially indicate Leslie's clearance level for this session.
The NMAS client then stores these credentials in a secret storage, and when Leslie attempts to access information, the server on which that information is stored asks Leslie's client for Leslie's NDS credentials. As requested, the NMAS client returns Leslie's encrypted credentials, at which point Leslie has an authenticated connection.
Although the authentication process may sound somewhat complex, this process actually occurs within fractions of a second.
NMAS AND THE RIGHT STUFF
If the IT team behind the scenes of "Mission: Impossible" had used NMAS to combine several login methods to protect the information Tom Cruise, a.k.a. Ethan Hunt, was after, the movie would have been ruined. Viewers wouldn't have been concerned with the drop of sweat that Hunt worried about. And it wouldn't have been a knife dramatically dropping to the floor that ultimately set off the alarms. Viewers would have sat bored, watching Hunt attempt in vain to steal information that was obviously inaccessible. Viewers would have known that Cruise just didn't have the face, the voice, or the smart card that he needed to get that information--even if he did have the right password.
Linda Kennard works for Niche Associates, an agency that specializes in technical writing and editing.
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.