Novell. Modular. Authentication Service (NMAS ª ) Security Services. WHITE PAPER

Transcription

1 Novell Modular Service (NMAS ª ) Security Services WHITE PAPER

2 table of contents Novell Modular 2 NMAS PROVIDES FLEXIBLE AND 7 SECURE edirectory edirectory VOLUME LABELS 2 USER DEFINED 8 CLEARANCE LEVEL ASSIGNMENTS 2 STANDARD edirectory 8 ENFORCED RESTRICTIONS 3 EXTENSIBLE edirectory THROUGH NMAS DUAL PRODUCT OFFERINGS 3 SIMPLE PASSWORD/HASH STARTER PACK 3 CLEAR TEXT ENTERPRISE EDITION 3 SHA-1 NOVELL CLIENT SUPPORT 3 MD-5 CERTIFIED MODULES 3 STANDARD edirectory PASSWORD 10 REQUIREMENTS 4 PHYSICAL DEVICE 10 NOVELL PARTNERSHIPS 5 BIOMETRIC 11 CONCLUSION 6 CONSOLEONE ª MANAGEMENT

3 2 Novell Modular NMAS provides flexible and secure edirectory ª authentication Today organizations are looking to make access to corporate resources even more secure by implementing stronger forms of authentication and authorization. Organizations are also working to remove the complexity and administrative overhead of having to maintain passwords throughout an organization. Novell Modular Service (NMAS, pronounced en-mass) enables and enhances strong authentication solutions while removing the complexity of authentication to edirectory ª. By supporting the leading smart card, token, biometrics, and digital certificate vendorõs authentication products, NMAS provides a way to centrally and easily manage the array of authentication methods organizations may wish to implement in their environment. Additionally, NMAS graded authentication allows administrators to create a security policy that grants access to file system or directory resources based on the strength and combination of the authentication. Finally, by implementing NMAS with a partner product, organizations can remove the requirement of a username and password for authentication against edirectory. USER DEFINED is the process of determining whether someone or something is, in fact, who or what it is declared to be. In private and public computer networks (including the Internet), authentication is commonly done through the use of logon passwords. Knowledge of the password is assumed to guarantee that the user is authentic. Each user registers initially (or is registered by someone else), using an assigned or self-declared password. On each subsequent use, the user must know and use the previously declared password. The weakness in this is that passwords can often be stolen, accidentally revealed, or forgotten. STANDARD edirectory Before the introduction of NMAS, edirectory used a very secure two-process mutual authentication method, known as Òpassword challenge responseó user authentication. The first process involved user login where a password and nonce (identifiers that are used only once) values generated by both the client and server were hashed twice using two different hash algorithms and later encrypted using an RSA* encryption algorithm. The second process involved background authentication to an edirectory server.

4 Novell Modular 3 EXTENSIBLE edirectory THROUGH NMAS While Novell makes a concerted effort to make its password challenge response authentication method secure, many edirectory-installed organizations have determined that password authentication is insufficient for their security needs. Such organizations have decided to expand their network authentication from Òsomething you knowó (for example, a password) to Òsomething you haveó (for example, a smart card), or Òsomething that you areó (for example, a fingerprint). The NMAS framework is extensible in that it allows for these and other forms of alternative authentication methods. NMAS-supported authentication methods include both authentication modules developed by Novell as well as by third parties. A summary of each of these authentication methods follows. SIMPLE PASSWORD/HASH With NMAS, Novell provides login methods common with LDAP, Internet browsers, and other directories. These include clear text, SHA-1, and MD-5 login methods. CLEAR TEXT Clear text (or plain text) authentication is a process of sending a password over the wire in an unencrypted form. Aside from no authentication at all, from a security standpoint, this is the lowest form of user authentication. Because there is no encryption process, plain text authentication is normally quite fast. This authentication method is included in NMAS to provide faster authentication in networks requiring less security, as well as to provide interoperability with systems that use clear text authentication (for example, FTP/Telnet and POP3 ). SHA-1 Developed and published by the National Institute of Standards and Technology (NIST) in 13 and 15, the secure hash algorithm (SHA-1) is a popular hash algorithm for network authentication. A hash (or message digest) is the transformation of a string of characters into a usually shorter fixed-length value or key that represents the original string. In terms of security, SHA-1/MD5 authentication is more secure than clear text because the password is altered when it travels across the network. is relatively fast because it is easy to compute a shorter hashed value. MD-5 Developed by Ron Rivest at MIT, this messagedigest algorithm takes a message of arbitrary length and produces a 128-bit message digest (or hash) output. MD-5 was, at one time, the most widely used secure hash algorithm. STANDARD edirectory PASSWORD As discussed previously, this is the password challenge response authentication method that uses different hash algorithms and, beginning with the release of NMAS, the DES (Data Encryption Standard) algorithm. The multiple ciphering

5 4 Novell Modular techniques provide a very secure password authentication method. Because of the increased security it offers, the standard edirectory password authentication is slower than clear text or SHA-1/MD5 authentication. PHYSICAL DEVICE Another way that userõs can authenticate is through the use of a physical object that the user carries with himself or herself and proves his or her identity (Òsomething you haveó) and is granted access accordingly. Third-party authentication developers have written authentication modules for two types of physical devices: smart cards and tokens. Smart Cards A smart card is a plastic card, about the size of a credit card, that includes an embedded microchip that can store data and perform cryptographic functions. Depending on what is stored on the microchip, a smart card can be used for a variety of tasks. With NMAS, a smart card can be used to establish an identity when authenticating to edirectory. For example, the ActivCard* Gold smart card lets a user prove his or her identity by using his or her private key and associated X.50 v3 user certificate that is stored on the smart card. Arcot* has also provided an NMAS module for authentication against edirectory via the Arcot WebFort*. PKI NMAS supports X.50 v3 certificates from the leading PKI vendors for authentication. NMAS 1.0 has an X.50 method that supports certificates and private keys wrapped in a cryptographically secure PKCS#12 file. Using these PKCS #12 files, users can authenticate against edirectory with their private key. NMAS 2.0 will have an advanced X.50 v3 method that not only supports authentication via PKCS#12, but also supports CRL and OCSP validation of the certificate via a validation service that runs on edirectory. This validation service and other features can be utilized by installing Novell Certificate Server ª 3.0. With NovellÕs Certificate Server 2.0 product that is shipped with NMAS, a network administrator has a directory integrated PKI (Public Key Infrastructure) where the administrator can issue X.50 v3 user certificates for, among other things, edirectory authentication. Token A token is a hand-held hardware device that generates a one-time password to authenticate its owner. Token authentication systems are based on one of two alternative schemes: challenge-response and time-synchronous authentication. By employing tokens, users do not need to use a weak password and the challenge and response occurs in such a way that replay attacks are thwarted. With the challenge-response approach, the user logs in to an authentication server, which then issues a prompt for a personal identification number (PIN) or a user ID. The user provides the PIN or ID to the server, which then issues a ÒchallengeÓÑa random number that appears on the userõs workstation. The user enters that

6 Novell Modular 5 challenge number into the token, which then encrypts the challenge with the userõs encryption key and displays a response. The user types in this response and sends it to the authentication server. While the user is obtaining a response from the token, the authentication server calculates what the appropriate response should be based on its database of user keys. When the server receives the userõs response, it compares that response with the one it has calculated. If the two responses match, the user is authenticated to the network. If they donõt match, access is denied. NMAS partners providing tokens include, but are not limited to: Vasco Data Security* provides an NMAS module for edirectory authentication using its Digipass* token. RSA Security* provides an NMAS module for edirectory authentication using the RSA SecurID token along with RSA ACE/Server* security software. BIOMETRIC Another authentication technique supported by edirectory is biometric authentication. Biometrics is the science and technology of measuring and statistically analyzing human body characteristics (Òsomething you areó). Biometric authentication can be classified into two groups: static biometric authentication and dynamic biometric authentication. Static biometric authentication captures and verifies physiological characteristics linked to the individual. Common static biometric characteristics include fingerprints, eye retinas and irises, and facial features. Dynamic biometric authentication captures and verifies behavioral characteristics of an individual. Common dynamic biometric characteristics include voice or handwriting. Biometric authentication requires readers or scanning devices, software that converts the scanned information into digital form, and, wherever the data is to be analyzed, a database or directory that stores the biometric data for comparison with entered biometric data. In converting the biometric input, the software identifies specific points of data as match points. The match points are processed using an algorithm into a value that can be compared with biometric data scanned when a user tries to gain access. Some of the biometric vendors whoõve partnered with Novell are: BioID has provided an NMAS module that uses a unique multi-modal biometric technology to recognize a combination of personal traits to grant or deny access to edirectory. Identicator*, a division of Identix*, provides an NMAS module for edirectory authentication using its BioLogon* 2.0 fingerprint authentication software. SAFLINK Corp.* provides at least three NMAS modules for edirectory authentication using licensed biometric authentication technology for facial, fingerprint, and voice authentication. SecuGen provides an NMAS module for fingerprint recognition within SecuGenÕs family of biometric PC peripherals to secure authentication against edirectory.

7 6 Novell Modular CONSOLEONE ª MANAGEMENT log in using Òsomething they areó and Òsomething NMAS is managed through NovellÕs Java ª authored, GUI-based, common management interface, ConsoleOne. ConsoleOne is an easy-to-install snap-in module. Specific ConsoleOne property pages let the administrator manage authentication methods, the sequence of those methods, and the security grade associated with those methods. Each of these management tasks is explained further below. Managing Methods. During the installation of the snap-in module, NMAS extends the edirectory schema and creates new objects in the edirectory treeõs Security container. These new objects are the Authorized Login Methods container and Login Policy objects. All authentication methods are stored and managed in the Authorized Login Methods container. By default, NMAS installs the standard edirectory password authentication method. Additional authentication methods can be installed using a wizard launched from the Authorized Login Methods container using the Create New Object option. Managing Sequences. Assigning how a user authenticates using NMAS is done by defining a login sequence and then enrolling a user with a method (e.g., password, token, biometric, etc.). Sequences incorporate one or more authentication methods and are stored in the Login Policy object in the Security container. A sequence includes the methods and the order in which those methods execute during user authentication. For example, suppose your organization implements a login policy that requires users to they know.ó As the administrator, you decide to require each user to authenticate using the Identicator BioLogon method, along with a SHA-1 password method. You would first decide the sequence of login prompts (Identicator prompt first followed by SHA-1 password or vice versa) and then create the sequence in the Login Sequences property page. The NMAS framework lets administrators easily chain both Novell and third-party authentication methods as part of a login sequence. No collaborative engineering work between different companies is needed. The NMAS framework does the collaboration. This makes it possible to create a sequence using the Identicator fingerprint reader, a Vasco token, and a standard edirectory password. Graded. This powerful feature lets administrators determine a scale or grade of the authentication methods supported and grant access rights accordingly. For example, the organizationõs security policy might specify that a biometric is a stronger form of authentication than a password. As a result, a user successfully authenticated with a biometric might receive access to a large set of resources because the administrator has greater confidence in that form of authentication. Conversely, a user authenticating to the network with a password might be granted a subset of access rights. This allows the administration of network access rights to be more finely controlled through authentication by requiring stronger forms of

8 Novell Modular 7 authentication from those users who need access to highly sensitive information and/or wider access. The example below demonstrates how NMAS could be implemented in a healthcare organization to control the confidentiality of medical records by ensuring that the proper level of authentication has occurred. Also notice that information contained on a NetWare volume designated as a secure location cannot be copied or moved to a volume with lower security restrictions. NMAS lets administrators assign any one of the following labels to edirectory volumes: Biometric & Password & Token Biometric & Password Biometric & Token Password & Token Biometric Password Token Logged In The access requirements associated with each of these labels are self-evident, except perhaps with the access requirements of the Logged In label, which enables access without requiring the use of a specific NMAS login method. All users who have authenticated to edirectory have at minimum, read-only rights to any volume labeled Logged In. edirectory VOLUME LABELS Graded authentication lets network administrators assign security labels to NetWare volumes based on the number and type of login factors deemed necessary to enable access to these volumes. For example, an administrator might assign a Biometric & Token label to a NetWare volume and subsequently create a login sequence that would include both a biometric and token authentication method. All edirectory volumes have the Logged In label by default, so an administrator must label only those volumes requiring restricted access. Below is a screenshot from ConsoleOne showing the properties of a user, Joe. Notice that Joe is authorized to login with Biometric & Token and Biometric. Additionally, Joe has Logged in as a default security clearance which will allow him to attach and read NetWare volumes if his ACLs permit.

9 8 Novell Modular ENFORCED RESTRICTIONS Users are prohibited from accessing edirectory volumes that require login factors that are not included in their clearance level. For example, a user with Biometric & Token clearance does not gain access to volumes labeled Biometric & Password & Token, nor could that user access CLEARANCE LEVEL ASSIGNMENTS Enforcing user access to labeled edirectory volumes is done through assigning clearance levels to users. At the discretion of the network administrator, an edirectory User object can be assigned one or many clearance levels. A userõs access is dependent on both the label of the edirectory volume and the clearance the user has when logging in. No matter what method a user uses to log in, he or she cannot access volumes with similar-method security labels unless he or she has been granted clearance that allows such access. The clearance level names are identical to the security label names. That is, an administrator can assign User objects clearance levels such as Biometric & Password & Token, Biometric & Password, Biometric & Token, and so on down the list shown above. In addition, administrators can assign a Multilevel Administration clearance. Multilevel Administration clearance provides read-write access to ALL areas on the networkñ a clearance that should be assigned to only a select few. volumes labeled Password. This ensures that users cannot access areas with security labels that are higher than or entirely different from their clearance level. Users are granted read-only access to volumes with labels that require fewer but at least one of the factors stated in their clearance level. For example, if a user is granted Biometric & Token clearance and requests that clearance at login, that user gains read-only access to volumes labeled Biometric and those labeled Token. In the example above, even though the userõs clearance level may appear to be sufficient to be granted read-write access to volumes labeled Biometric and those labeled Token, the user is intentionally denied read-write access. This is a security measure to ensure that confidential information remains on the volume where it resides without that information being accidentally or maliciously copied to an area where it should not be stored. DUAL PRODUCT OFFERINGS NMAS is available in two product offerings, namely the Novell Modular Service Starter

10 Novell Modular Pack and the Novell Modular Service Enterprise Edition. Each are described in detail below. STARTER PACK Available as a free Web download and bundled with certain Novell products, the Novell Modular Service Starter Pack lets network administrators create single-method login sequences using any of the available Novell methods. This way, administrators can set up departments and even individual user access to edirectory volumes according to perceived security needs. CERTIFIED MODULES Novell assures the compatibility of the methods available for Web download or included in either product, by insuring that each pass the ÒYesÑ Tested and ApprovedÓ and ÒeDirectory EnabledÓ certification tests. To maintain the assurance that the modules remain unaltered, NMAS will only allow Novell digitally signed modules to be installed. As Novell works with more partners to develop authentication modules, Novell will continue to test and certify new modules. Upon certification, these digitally signed modules may be made available to NMAS users through Web download. ENTERPRISE EDITION Available as a for-purchase product, the Novell Modular Service Enterprise Edition allows for multi-factor authentication by allowing one or more Novell or third party methods to be chained together in a desired sequence order. In addition, the graded authentication feature allows administrators to base volume access rights according to the methods used for authentication at login. NOVELL CLIENT SUPPORT Novell has updated its Windows* 5/8 and Windows NT* clients to efficiently support the NMAS login methods. With NMAS, edirectory users can indicate the login sequence that they will use to log in to edirectory and, if needed, the clearance they need. The login sequence and clearance may be selected in a new tabbed page in the Novell Client ª login dialog. REQUIREMENTS Server: NetWare 5.1 SP2 with edirectory 8 or Windows NT/2000 with edirectory 8.5 and NICI 1.5 Client Platform: Windows NT 4 SP3 or higher, Windows 5 OSR2B, or Windows 8 SP1 Novell Client: Novell Client for Windows 5/8 version 3.2 or higher Novell Client for Windows NT/2000 version 4.7 or higher Processor: 486/33 or higher Memory: 64 MB minimum on server; 40 MB on client Hard Disk Space: 100 MB of available disk space on the NetWare 5 server. Note: If PKIS 2.0 and ConsoleOne are already installed, only 10 MB is required. Rights: Administrator rights to the NetWare 5 server to install NMAS from a client; NT administrator rights to install client software on Windows NT

11 NOVELL PARTNERSHIPS Novell encourages vendors of authentication devices to contact Novell for potential partnerships, including partnerships in both integration and marketing. Also, Novell has streamlined the integration process between Integrated Service Vendors (ISV) and Novell, enabling Novell ISVs working with Novell shops to integrate with NMAS in as little as one week. To inquire on more details contact Novell toll-free at (800) and ask for an NMAS Product Manager. CONCLUSION As organizations look to provide enhanced security to their networks, choosing to implement different and multiple login methods is a logical approach. NMAS makes implementing an advanced authentication system in your edirectory tree easy and painless. Novell partners with the worldõs leading authentication developers to provide a solid security framework that allows many different forms of authentication to work together to provide enhanced security in edirectory managed networks. Graded authentication provides the ability to grant access rights according to the authentication method used. This allows network access rights to be finely controlled through authenticationñ an additional layer of security protecting sensitive data. NMAS is one of many components that build solutions that deliver on the One Net vision at Novell. By simplifying security administration, securing access to data, and accelerating productivity, NMAS gives your organization the power to change with Net services software from Novell. Copyright 2001, Novell, Inc. All rights reserved. Novell and NetWare are registered trademarks, and ConsoleOne, edirectory, NMAS, Novell Certificate Server and Novell Client are trademarks of Novell, Inc. in the United States and other countries. *All third-party trademarks are the property of their respective owners. Novell Product Training and Support Services For more information about Novell s worldwide product training, certification programs, consulting and technical support services, please visit: For More Information Contact your local Novell Authorized Reseller, or visit the Novell Web site at: You may also call Novell at: US/Canada Worldwide Facsimile Novell, Inc South Novell Place Provo, Utah USA