Security Target IBM Tivoli Directory Server Version 5.2 Version: 1.5 Status: Final version Last update: 2003-11-10 IBM Tivoli Directory Server Version 5.2 Copyright IBM 2003 PAGE 1 IBM Tivoli Directory Server Version 5.2 Document History Version Date Changes Summary Author 1.0 2003-07-09 Initial version Initial version produced by IBM Steve Omrani and Staffan Persson 1.1 2003-07-31 Updates due to findings during evaluation Steve Omrani 1.2 2003-10-02 Updated due to BSI comment Staffan Persson 1.3 2003-10-06 Updates due to extended operation Staffan Persson 1.4 2003-10-29 Updated due to comments on F.I&A and FIA_AFL.1 Staffan Persson 1.5 2003-11-10 Removing accountability claims for the administrator group Staffan Persson Copyright IBM 2003 PAGE 2 IBM Tivoli Directory Server Version 5.2 Table of contents 1 Introduction....................................................................................................................................... 6 1.1 ST Identification........................................................................................................................... 6 1.2 ST Overview................................................................................................................................ 6 1.3 IBM Tivoli Directory Server Overview ........................................................................................ 6 1.4 CC Conformance Claim.............................................................................................................. 6 1.5 Strength of Function Claim......................................................................................................... 6 2 TOE Description............................................................................................................................... 7 2.1 Product Type ............................................................................................................................... 7 2.1.1 Defining a Directory......................................................................................................... 7 2.1.2 Directory clients and servers........................................................................................... 8 2.1.3 Directory security............................................................................................................. 8 2.1.4 Directory Architecture and Operations........................................................................... 8 2.2 Security Roles and Services....................................................................................................... 9 2.2.1 Delivered Core Services ................................................................................................. 9 2.2.2 Security Roles.................................................................................................................. 9 2.2.2.1 Directory Administrator ...................................................................................... 9 2.2.2.2 Administrative Group Members....................................................................... 10 2.2.2.3 End User........................................................................................................... 10 2.2.3 Auxiliary Services........................................................................................................... 10 2.3 TOE Boundary........................................................................................................................... 11 3 TOE Security Environment........................................................................................................... 13 3.1 Secure Usage Assumptions..................................................................................................... 13 3.2 Threats to security..................................................................................................................... 13 3.2.1 Threats addressed by TOE........................................................................................... 13 3.2.2 Threats addressed by the operating environment....................................................... 14 3.3 Organizational Security Policies............................................................................................... 14 4 Security Objectives........................................................................................................................ 15 4.1 TOE Security Objectives........................................................................................................... 15 4.2 Environmental Security Objectives .......................................................................................... 15 5 IT Security Requirements ............................................................................................................. 16 5.1 TOE Security Functional Requirements .................................................................................. 16 5.1.1 FAU_GEN.1 Audit data generation.............................................................................. 16 5.1.2 FAU_GEN.2 User identity association ......................................................................... 17 5.1.3 FAU_SAR.1 Audit review.............................................................................................. 17 5.1.4 FAU_SAR.2 Restricted audit review ............................................................................ 17 5.1.5 FDP_ACC.2 Complete access control......................................................................... 17 5.1.6 FDP_ACF.1 Security attribute based access control.................................................. 18 5.1.7 FIA_AFL.1 Authentication failure handling................................................................... 19 5.1.8 FIA_ATD.1 User attribute definition.............................................................................. 19 5.1.9 FIA_SOS.1 Verification of secrets................................................................................ 20 5.1.10 FIA_UAU.1 Timing of authentication............................................................................ 20 5.1.11 FIA_UID.1 Timing of identification ................................................................................ 20 5.1.12 FMT_MOF.1a Management of security functions behaviour ..................................... 20 5.1.13 FMT_MOF.1b Management of security functions behaviour ..................................... 21 5.1.14 FMT_MSA.1 Management of security attributes......................................................... 21 5.1.15 FMT_MSA.3 Static attribute initialisation...................................................................... 21 5.1.16 FMT_MTD.1 Management of TSF data....................................................................... 21 5.1.17 FMT_SMF.1 Specification of Management Functions................................................ 21 Copyright IBM 2003 PAGE 3 IBM Tivoli Directory Server Version 5.2 5.1.18 FMT_SMR.1 Security roles........................................................................................... 22 5.1.19 FPT_RVM.1 Non-bypassability of the TSP.................................................................. 22 5.2 TOE Environment Security Functional Requirements............................................................ 22 IT Security Requirements for the underlying Operating System ............................................. 22 5.2.1 FPT_STM.1 Reliable time stamps................................................................................ 22 Non-IT Security Requirements for the TOE Environment........................................................ 22 5.3 TOE Security Assurance Requirements.................................................................................. 23 6 TOE Summary Specification........................................................................................................ 24 6.1 TOE Security Functions............................................................................................................ 24 6.1.1 F.AUDIT ......................................................................................................................... 24 6.1.1.1 Audit Generation (F.AUDIT.1)......................................................................... 24 6.1.2 F.ACCESS_CONTROL................................................................................................ 26 6.1.2.1 Order of Evaluation .......................................................................................... 27 6.1.2.2 Access Control Attributes ................................................................................ 28 6.1.3 F.I&A............................................................................................................................... 28 6.1.3.1 User Authentication (F.I&A.1).......................................................................... 28 6.1.4 F.MANAGEMENT ......................................................................................................... 29 6.1.4.1 Roles (F.MANAGEMENT.1)............................................................................ 29 6.1.4.2 Authentication Function (F.MANAGEMENT.2).............................................. 30 6.1.4.3 Authorization Functions (F.MANAGEMENT.3).............................................. 32 6.1.4.4 Audit Function (F.MANAGEMENT.4)............................................................. 32 6.1.5 F.REF_MEDIATION...................................................................................................... 33 6.1.6 TOE Security Functions rationale................................................................................. 33 6.2 Assurance Measures................................................................................................................ 33 7 Protection Profile Claims.............................................................................................................. 36 7.1 PP Reference............................................................................................................................ 36 8 Rationale.......................................................................................................................................... 37 8.1 Security Objectives Rationale................................................................................................... 37 8.2 Security Requirements Rationale............................................................................................. 39 8.2.1 Security Functional Requirements Rationale............................................................... 39 8.2.2 Dependency analysis.................................................................................................... 42 8.2.3 Demonstration of mutual support between security requirements............................. 43 8.2.4 Non-IT security requirements rationale........................................................................ 44 8.2.5 Appropriateness of assurance requirements............................................................... 44 8.3 TOE Summary Specification Rationale ................................................................................... 45 8.3.1 TOE Security Functions rationale................................................................................. 45 8.3.2 Minimum Strength of Function Level rationale ............................................................ 48 8.4 Assurance measures rationale................................................................................................. 48 Copyright IBM 2003 PAGE 4 IBM Tivoli Directory Server Version 5.2 List of figures Figure 1: IBM Tivoli Directory Architecture and TOE Boundary........................................................... 12 List of tables Table 1: Summary of Security Functional Requirements for the TOE................................................. 16 Table 2: TOE assurance components ................................................................................................... 23 Table 3: Assurance Measures................................................................................................................ 33 Table 4: Mapping of Security Objectives to Threats, Assumptions and Policies................................. 37 Table 5: Mapping of Security Functional Requirements to TOE Security Objectives......................... 39 Table 6: Dependency Mapping of Security Functional Requirements................................................. 42 Table 7: Mapping of non-IT Security Requirements to Security Objectives for the Environment ...... 44 Table 8: Mapping of Security Functions to Security Functional Requirements................................... 45 Table 9: Mapping of Assurance Measures to Assurance Requirements ............................................ 48 References [CC] Common Criteria for Information Technology Security Evaluation, CCIMB-99-031, Version 2.1, August 1999 [CEM] Common Methodology for Information Technology Security Evaluation, CEM-99/045, Part 2 - Evaluation Methodology, Version 1.0, 1999 [GUIDE] ISO/IEC PDTR 15446 Title: Information technology – Security techniques – Guide for the production of protection profiles and security targets, ISO/IEC JTC 1/SC 27 N 2449, 2000-01-04 [RFC1777] Lightweight Directory Access Protocol, RFC 1777 [RFC2251] Lightweight Directory Access Protocol (v3), RFC 2251 [RFC2252] Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions, RFC 2252 [RFC2253] Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names, RFC 2253 [RFC2254] The String Representation of LDAP Search Filters, RFC 2254 [RFC2255] The LDAP URL Format, RFC 2255 [RFC2256] A Summary of the X.500(96) User Schema for use with LDAPv3, RFC 2256 Copyright IBM 2003 PAGE 5 IBM Tivoli Directory Server Version 5.2 1 Introduction 1.1 ST Identification Title: Security Target for the IBM Tivoli Directory Server Version 5.2 Assurance level: EAL 3 Keywords: Light weight Directory Access Protocol (LDAP), Access Control List (ACL), Password Policy (PP), Audit Service (AS), IBM Tivoli Directory Server (ITDS) 1.2 STOverview This document is the Security Target (ST) for the IBM Tivoli Directory Server Version 5.2. This Directory Server is running on Microsoft Windows 2000, IBM AIX 5.2, Sun Solaris 8, HP- UX 11i, Red Hat Advanced Server 3.0 and SuSE Linux Enterprise Server 8. The Security Target has been developed in accordance with the Common Criteria for Information Technology Security Evaluation (CC) version 2.1, for a claimed Evaluation Assurance Level 3 (EAL 3). 1.3 IBM Tivoli DirectoryServer Overview IBM Tivoli Directory Server version 5.2 (ITDS) is an implementation of Lightweight Directory Access Protocol (LDAP), which is compliant with the Internet Engineering Task Force (IETF) LDAP Version 2 specifications, i.e. RFC 1777 and LDAP Version 3 specifications, i.e. RFC 2251-2256. The server is a software only product and can be installed and operated on variety of hardware/software platforms. LDAP is essentially a specialized database where the update operation is less frequent and dedicated to the common goal within the enterprise on consolidating and unifying the management of identity. ITDS is built for identity management with role supports, fine-grained access control and entry ownership. It provides the foundation for improved security, rapid development and deployment of Web applications. Using the power of the IBM DB2 Universal Database as back end data store, ITDS provides high performance, reliability and stability in an enterprise or e-business. As the central repository for data within an enterprise, it is a powerful, secure and standards compliant enterprise directory for corporate intranets and the Internet. 1.4 CCConformanceClaim The ST is Part 2 conformant and Part 3 conformant to the CC. This means that it is conformant with the security functional requirements as specified in CC Part 2, and with the security assurance requirements for Evaluation Assurance Level 3 (EAL 3), as specified in Part 3 of the CC. 1.5 Strength of Function Claim The TOE contains one non-cryptographic security function that is realized by a probabilistic or permutational mechanism, i.e. password based authentication. The minimum strength level claimed for this function is SOF-basic. Thus, the global minimum strength level claimed for the TOE is also SOF-basic. Copyright IBM 2003 PAGE 6 IBM Tivoli Directory Server Version 5.2 2 TOE Description This section describes the Target of Evaluation (TOE) in terms of the class of product, the operational environment, and the provided security functionality. This chapter provides a general description of the product without focusing on the evaluated configuration. 2.1 ProductType The IBM Tivoli Directory Server Version 5.2 (ITDS) is an implementation of the Lightweight Directory Access Protocol (LDAP) and meets the requirements of LDAP Version 3 as defined in RFC 2251–2256 and LDAP Version 2 as defined in RFC 1777. The product consists of two major components: the LDAP Server and the LDAP Server Administration Daemon. The TOE described in this ST includes both of them. The server may be partitioned into two parts; the Front-end and the Back-end. The Front-end is the network interface to LDAP clients and the Back-end is the interface to the DB2 database. The Administration Daemon provides an LDAP interface to clients, used for the administration of the LDAP server. The ITDS Version 5.2 is a software product only, delivered over the Internet as a package including the TOE, user and administrative tools, a WebSphere HTTP server, and a DB2 database. The user and administrator tools, the HTTP server and the DB2 database are all excluded from the TOE and are considered part of the environment. The TOE environment must also include applications that are not delivered with the ITDS product, but are used as unprivileged tools, for example the Netscape browser needed to administrate the TOE or the Adobe Acrobat Reader to access the supplied online documentation. 2.1.1 Defining a Directory A directory is a collection of information about objects arranged in some order that gives details about each object. It is a specialized database, which stores typed and ordered information about objects. Directories enable users or applications to find resources that have the characteristics needed for a particular task. If the name of an object is known, its characteristics can be retrieved. If the name of a particular individual object is not known, the directory can be searched for a list of objects that meet a certain requirement. Directories can usually be searched by specific criteria, not just by a predefined set of categories. A directory is a specialized database that has characteristics that set it apart from general purpose relational databases. A characteristic of a directory is that it is accessed (read or searched) much more often than it is updated (written). Because directories must be able to support high volumes of read requests, they are typically optimized for read access. Because directories are not intended to provide as many functions as general-purpose databases, they can be optimized to economically provide more applications with rapid access to directory data in large distributed environments. A directory can be centralized or distributed. If a directory is centralized, there is one directory server (or a server cluster) at one location that provides access to the directory. If the directory is distributed, there is more than one server, usually geographically dispersed, that provides access to the directory. When a directory is distributed, the information stored in the directory can be partitioned or replicated. When information is partitioned, each directory server stores a unique and non- overlapping subset of the information. That is, one and only one server stores each directory entry. The technique to partition the directory is to use LDAP referrals. LDAP referrals allow the users to refer Lightweight Directory Access Protocol (LDAP) requests to either the same or different name spaces stored in a different (or same) server. When information is Copyright IBM 2003 PAGE 7 IBM Tivoli Directory Server Version 5.2 replicated, more than one server stores the same directory entry. In a distributed directory, some information may be partitioned, and some information may be replicated. 2.1.2 Directory clients and servers Directories are usually accessed using the client-server model of communication. The client and server processes might or might not be on the same machine. A server is capable of serving many clients. An application that wants to read or write information in a directory does not access the directory directly. Instead, it calls a function or application programming interface (API) that causes a message to be sent to another process. This second process accesses the information in the directory on behalf of the requesting application. The results of the read or write are then returned to the requesting application. An API defines the programming interface a particular programming language uses to access a service. The format and contents of the messages exchanged between client and server must adhere to an agreed upon protocol. LDAP defines a message protocol used by directory clients and directory servers. There is also an associated LDAP API for the C language and ways to access the directory from a Java application using the Java Naming and Directory Interface (JNDI). 2.1.3 Directory security A directory should support the basic capabilities needed to implement a security policy. The directory might not directly provide the underlying security capabilities, but it might be integrated with a trusted network security service that provides the basic security services. First, a method is needed to authenticate users. Authentication verifies that users are who they say they are. A user ID and password is a basic authentication scheme. Once users are authenticated, it must be determined if they have the authorization or permission to perform the requested operation on the specific object. Authorization is often based on access control lists (ACLs). An ACL is a list of authorizations that may be attached to objects and attributes in the directory. An ACL lists what type of access each user or a group of users is allowed or denied. In order to make ACLs shorter and more manageable, users with the same access rights are often put into groups. 2.1.4 Directory Architecture and Operations LDAP defines the content of messages exchanged between an LDAP client and an LDAP server. The messages specify the operations requested by the client (search, modify, delete, and so on), the responses from the server, and the format of data carried in the messages. LDAP messages are carried over TCP/IP, a connection-oriented protocol; so there are also operations to establish and disconnect a session between the client and server. The general interaction between an LDAP client and an LDAP server takes the following form: • The client establishes a session with an LDAP server. This is known as binding to the server. The client specifies the host name or IP address and TCP/IP port number where the LDAP server is listening. The client can provide a user name and a password to properly authenticate with the server. Or the client can establish an anonymous session using bind with default access rights. The client and server can also establish a session that uses stronger security methods such as encryption of data. • The client then performs operations on directory data. LDAP offers both read and update capabilities. This allows directory information to be managed as well as queried. LDAP also supports searching the directory for data meeting arbitrary user- specified criteria. Searching is a very common operation in LDAP. A user can specify Copyright IBM 2003 PAGE 8 IBM Tivoli Directory Server Version 5.2 what part of the directory to search and what information to return. A search filter that use Boolean conditions, specifies what directory data matches the search. • When the client is finished making requests, it closes the session with the server. This is also known as unbinding. Note: Unauthenticated users are users that have not performed a bind, while anonymous users are users that have performed a bind without providing a Distinguished Name (DN) or password. Apart from distinguishing between the two when logging, there is no difference in the way unauthenticated and anonymous users are being treated by the TOE. For this reason we will use the term unauthenticated both for the anonymous and the unauthenticated. The administrator may configure the TOE not to accept any unauthenticated or anonymous users. 2.2 SecurityRolesandServices 2.2.1 Delivered Core Services The server allows authorized clients to: • Add entries to the directory, • Delete entries from the directory, • Modify the attributes of an entry, • Modify the Distinguished Name (DN). For LDAPv2 this operation is called Modify Relative Distinguished Name (RDN), • Search the directory for entries that meet certain filter criteria, • Compare to check for presence of entries or attributes matching the compare criteria, • Abandon (terminate) a LDAP operation, • Extended operations, which are server side enhancements to the LDAP operations as delivered by IBM. In addition, the server may allow unauthenticated users to perform any operation on any entries or attributes that are not blocked by any ACL. 2.2.2 Security Roles The ITDS supports three different security roles: Directory Administrator, Member of the Administrative Group and End User. A user account for the TOE is being one, and only one of these three roles. Only by having different accounts a user may act in different roles. The following sections describe the capability of each one. Note that ITDS has its own definition of roles, which is similar to LDAP groups and should not be confused with the security roles. The only difference between roles and groups is that when a user is assigned to a role, there is an implicit expectation that the necessary authority has already been set up to perform the job associated with that role. With group membership, there is no built-in assumption about what permissions are gained (or denied) by being a member of that group. In this evaluation, the groups and roles are regarded as authorization attributes instead. 2.2.2.1 Directory Administrator The Directory Administrator is associated with a specific user account. There is only one Directory Administrator account for the LDAP server. The Directory Administrator has the full rights to manage the LDAP server. Copyright IBM 2003 PAGE 9 IBM Tivoli Directory Server Version 5.2 The Directory Administrator is created during product installation. It consists of a user ID and a password and predefined authorization to manipulate the entire directory. The Directory Administrator creates the End User security role. This is an LDAP entry with a specific Distinguished Name (DN), User Password and other attributes that represent the particular End user. The Directory Administrator also defines the level of authorization the End User will have over entries. 2.2.2.2 Administrative Group Members Administrative group members are users that have been assigned a subset of administrative privileges. All administrative group members have the same set of privileges. The administrative group is a way for the Directory Administrator to delegate a limited set of administrative tasks to one or more individual user accounts. These users can perform most administrative tasks. Excepted are operations that may increase the privileges of those users, such as change the password of the Directory Administrator. 2.2.2.3 End User End Users are users without any specific privileges. Each End User is identified with an LDAP entry containing the authentication and authorization information for that End User. The authentication and authorization information may also allow the End User to query and update other entries. The user ID and password are validated during the bind operation. Once the End User ID and password are validated, the End User may access any of the attributes of any entry to which he has permissions. 2.2.3 Auxiliary Services In addition to the implementation of Lightweight Directory Access Protocol (LDAP), the ITDS also includes enhancements added by IBM in functional and performance areas. This version uses the IBM DB2 ® as the backing store to provide per LDAP operation transaction integrity, high performance operations, and on-line backup and restore capability. It interoperates with the IETF LDAP V3 and V2 based clients. Besides supporting the standard LDAP operations, it additionally includes the following features: • Administration and configuration for the IBM Tivoli Directory Server is provided by LDAP clients being either a Web browser-based GUI or command line clients. The administration and configuration functions allow the administrators to: o Perform the initial setup of the directory o Change configuration parameters and options o Manage the daily operations of the directory The administrative tasks of the TOE are mainly done through LDAP operations on the ITDS. For starting, stopping, restarting and querying the status of the ITDS, LDAP operations are performed on the administration daemon, which then will carry out the operations on the directory server. • A dynamically extensible directory schema – This means that administrators can define new attributes and object classes to enhance the directory schema. Users may dynamically modify the schema content without restarting the directory server. Since the schema itself is part of the directory, schema update operations are done through standard LDAP APIs. The following functions are provided by the ITDS to determine the status of the server and the LDAPv3 dynamic extensible schema: o Query of the schema information through LDAP APIs o Dynamic schema changes through LDAP APIs o Server rootDSE can be queried for status information of the server Copyright IBM 2003 PAGE 10 IBM Tivoli Directory Server Version 5.2 o Dynamic configuration changes using LDAP APIs • UTF-8 (Universal Character Set Transformation Format) – The ITDS supports data in multiple languages, and allows users to store, retrieve and manage information in a native language code page. • Simple Authentication and Security Layer (SASL) – This support provides for additional authentication mechanisms, which is a plug-in facility to allow different authentication methods to be used. The SASL mechanism is not part of the TOE. The user ID and password is the basic authentication scheme used and being part of this TOE. The passwords selected by End Users are subject to the password policy determined by the Directory Administrator. • The Transport Layer Security (TLS) and Secure Sockets Layer (SSL) provide encryption of data and authentication using X.509v3 public-key certificates. A server may be configured to run with or without TLS or SSL support. However, TLS and SSL support is not part of the TOE but part of the TOE environment. • Replication – Replication is supported, which makes additional read-only copies of the directory available, improving performance and reliability of the directory service. However, replication is not part of the evaluated configuration of the TOE. • Referrals – Support for LDAP referrals, allowing directories to be distributed across multiple LDAP servers where a single server may only contain a subset of the whole directory data. • Access Control Model – A powerful, easy-to-manage access control model on LDAP objects (entries or attributes) is supported through ACLs. • Change log – Changes made to the LDAP data are being logged internally in the LDAP server to support replication of these information. However, replication is not part of the TOE. • Security audit logging – Auditing of the LDAP operations is provided by the security auditing logging. • A dynamic tracing facility is provided, which can be activated and deactivated by the administrator and members of the administrative group using extended operations. The dynamic tracing facility must not be activated as part of the evaluated configuration of the TOE. 2.3 TOEBoundary Figure 1 illustrates the client/server based ITDS architecture. The rectangle represented by the dash lines indicates the TOE boundary, i.e. the standalone Directory Sever and the Administration Daemon is the Target of Evaluation. Those, out of the scope of evaluation, are listed as below: • The underlying hardware and operating system of the Directory Server • The database, which serves as the back end data store of the directory • The LDAP client • The TLS/SSL module, which provides trust path between LDAP client and ITDS, and also provides trust path among replication servers • The replication service The underlying hardware and operating system, the database, the LDAP client and the TLS/SSL module are part of the TOE environment. Copyright IBM 2003 PAGE 11 IBM Tivoli Directory Server Version 5.2 The TOE consists of two components: the directory server component and the administration daemon. User clients may connect both to the LDAP server (shown in the picture as the Directory Server) and to the administration daemon, using the LDAP protocol, but using different port numbers. The directory server is providing the LDAP functionality to End Users, the Administrative Group Members and the Directory Administrator, while the administration daemon is only used by the Administrative Group Members and the Directory Administrator for starting, stopping and querying the status of the ITDS. LDAP Client Operating System and Hardware Directory Server Database TOE Boundary Administration Daemon TLS/ SSL TCP/IP Figure 1: IBM Tivoli Directory Architecture and TOE Boundary Note: Note that the hardware and the operating system the ITDS uses are part of the TOE environment. Note also that the TLS or SSL protocol (when used) has to be provided by the TOE environment. The TOE assumes a secured communication link between itself and the client as well as between itself and the database. Copyright IBM 2003 PAGE 12 IBM Tivoli Directory Server Version 5.2 3 TOE Security Environment 3.1 SecureUsageAssumptions The following conditions are assumed to exist in the TOE operational environment. These assumptions include essential environmental constraints on the secure use of the TOE. A.PHYSICAL The TOE is operated in a physically secure environment. A.NOEVIL The TOE Administrators (i.e. the Directory Administrator and the Administrative Group Members) and TOE Environment Administrators are trustworthy to perform discretionary actions in accordance with security policies and not to interfere with the abstract machine. A.ADMIN The TOE and TOE environment are competently installed and administered. A.COMM It is assumed that a communication link exists from the TOE to LDAP clients on external systems, and that any communication links between the TOE and external systems are protected against unauthorized modification and disclosure of communication data. A.COOP Authorized end users are trusted and expected to act in a cooperating manner in a benign environment. A.TIME It is assumed that a reliable time function is provided by the TOE environment. 3.2 Threats to security The threats are categorized as those addressed by the TOE and those addressed by the environment. The assets held in the TOE are information and resources under the control of the TOE, such as directory entries and TSF data. It is assumed that an attacker is either an unauthorized user of the TOE, or an authorized user of the TOE who has been granted rights to access the information or resources held by the TOE. The attacker is assumed to have limited resources and to come from a well-managed user community in a non-hostile working environment. The TOE is not intended to be used in an environment in which protection against determined or sophisticated attacks is required. 3.2.1 Threats addressed by TOE The TOE address the threats discussed below. • T.ENTRY: An illegitimate user (i.e. one other than authenticated user) could gain unauthorized, malicious access to resources or information, other than public information, protected by the TOE. • T.ACCESS: A legitimate user of the TOE could gain unauthorized access to a resources or information protected by the TOE, or perform operations for which no access rights have been granted, via user error, system error, or other actions. A legitimate user is someone who is: o authenticated uniquely by the ITDS, or o unauthenticated, and appears as an anonymous user. Copyright IBM 2003 PAGE 13 IBM Tivoli Directory Server Version 5.2 • T.ACCOUNT: Security relevant actions occur without awareness by Directory Administrators. Lack of accountability of security relevant events of user or system processes may lead to failure in identifying possible security violations and holding those responsible accountable. • T.BYPASS: An attacker may bypass TOE security functions to gain access to resources or information protected by the TOE. 3.2.2 Threats addressed by the operating environment The threats discussed below must be countered in order to support the TOE security capabilities but are either: • not addressed by, or • only partly addressed by the TOE Such threats must therefore be addressed in conjunction with the operating environment. • TE.USAGE: The TOE may be configured, used and administered in an insecure manner, allowing an illegitimate user gaining access to resources or information protected by the TOE. • TE.CRASH: Human error or a failure of software, hardware, power supply, or an accidental event may cause an abrupt interruption to the TOE operation, resulting in loss or corruption of data. • TE.SOPHISTICATED: An unauthorized individual may gain access to TOE resources or information by using sophisticated technical attack, using IT security- defeating tools applied to the TOE or the underlying system components. • TE.PASS: An attacker may bypass the TOE to access resources or resources protected by the TOE by attacking the underlying operating system or database, in order to gain access to TOE resources and information. 3.3 Organizational SecurityPolicies The TOE complies with the following organizational security policy: • P.PUBLIC: Of the information under the control of the TOE, only information classified as public information should be made available to unauthenticated or anonymous users, if such users are giving access to the TOE. Copyright IBM 2003 PAGE 14 IBM Tivoli Directory Server Version 5.2 4 Security Objectives This section defines the security objectives for the TOE and its environment respectively. 4.1 TOE SecurityObjectives The following lists the security objectives that the TOE meets. O.AUTHENTICATE The TOE must ensure that all users are identified and authenticated before being granted access to the TOE mediated resources except for allowing unauthenticated users to perform some operations on public data. Such limited access to the TOE is configured by Directory Administrator and Members of the Administrative Group and should be compliant with the security policy of the organization responsible for the operation of the TOE. O.AUTHORIZE The TOE must provide the ability to specify and manage access rights to objects and services by user and system process. O.ACCOUNT The TOE must ensure that all TOE users can subsequently be held accountable for their security relevant actions, except for unauthenticated users, who may be granted limited access to TOE. O.BYPASS The TOE security policy enforcement functions must be invoked and succeed before access to TOE objects and services are allowed. 4.2 Environmental SecurityObjectives Some security needs are beyond the capability of the TOE to adequately satisfy without support from the TOE operational environment. Those security needs derive environmental security objectives which are listed as below: OE.MANAGE Those responsible for the TOE must ensure that the TOE is installed, and managed in a secure manner, which maintains the security of the TOE, TSF data and user data of the TOE. OE.OS-MANAGE Those responsible for the TOE must ensure that the underlying operating system and hardware is configured and managed in a secure manner. OE.PHYSICAL Those responsible for the TOE must ensure that the TOE and its underlying hardware and software are physically protected from unauthorized physical access and tampering. OE.DATABASE The database used to store the TSF and user data is configured and managed in a secure way that prohibits unauthorized access and tampering with the TSF data and user data of the TOE. OE.SOPHISTICATED The TOE environment must sufficiently counter the threat of an individual (other than an authorized user) gaining unauthorized access via sophisticated technical attack. OE.BACKUP The TOE environment must provide backup facility for recovery to a secure state following a system failure, discontinuity of service, or detection of an insecure status. This includes the provisions necessary to ensure the availability of the TSF data and user data stored outside of the TOE. OE.COMMUNICATION The communication links between the TOE and LDAP clients on external systems are protected from unauthorized modification and disclosure of communication data OE.TIME The TOE environment must provide a reliable time source. Copyright IBM 2003 PAGE 15 IBM Tivoli Directory Server Version 5.2 5 IT Security Requirements This section contains the security functional requirements (SFRs) and security assurance requirements (SARs) that must be satisfied by the TOE. These requirements consist of functional components from Part 2 of the CC and Evaluation Assurance Level (EAL) 3 assurance components from Part 3 of the CC, respectively. 5.1 TOE SecurityFunctional Requirements This section identifies and specifies the SFR components that the TOE, is intended to meet for the purposes of this CC evaluation. All of these SFR components are chosen from Part 2 of the CC to directly or indirectly (i.e., via a functional component dependency) satisfy the security objectives for the TOE, summarized in Table 1. Operations that are completed on the SFR components are indicated throughout this section through the use of Bold Italic text. The iteration operation has only been performed once for FMT_MOF.1. The two SFR components are identified as FMT_MOF.1a and FMT_MOF.1b. Table 1: Summary of Security Functional Requirements for the TOE SFR Components Identifier Name FAU_GEN.1 Audit data generation FAU_GEN.2 User identity association FAU_SAR.1 Audit review FAU_SAR.2 Restricted audit review FDP_ACC.2 Complete access control FDP_ACF.1 Security attribute based access control FIA_AFL.1 Authentication failure handling FIA_ATD.1 User attribute definition FIA_SOS.1 Verification of secrets FIA_UAU.1 Timing of authentication FIA_UID.1 Timing of identification FMT_MOF.1a Management of security functions behavior FMT_MOF.1b Management of security functions behavior FMT_MSA.1 Management of security attributes FMT_MSA.3 Static attribute initialization FMT_MTD.1 Management of TSF data FMT_SMF.1 Specification of Management Functions FMT_SMR.1 Security Roles FPT_RVM.1 Non-bypassability of the TSP 5.1.1 FAU_GEN.1 Audit data generation FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable events: a) Start-up and shutdown of the audit functions; b) All auditable events for the not specified level of audit; c) Including the following events: • Bind (LDAP v2 and v3) • Unbind (LDAP v2 and v3) Copyright IBM 2003 PAGE 16 IBM Tivoli Directory Server Version 5.2 • Search (LDAP v2 and v3) • Add (LDAP v2 and v3) • Modify (LDAP v2 and v3) • Delete (LDAP v2 and v3) • ModifyDN (LDAP v3) and ModifyRDN (LDAP v2) operations • Event notification (LDAP v3) • Extended operations (LDAP v3) FAU_GEN.1.2 The TSF shall record within each audit record at least the following information: a) Date and time of the event, type of event, subject identity, and the outcome (success or failure) of the event; and b) For each audit event type, based on the auditable event definitions of the functional components included in the ST: none Application Note: The subject identity for unauthenticated or anonymous users assigned will be the one of the unauthenticated or anonymous user identify. The subject identity for the start-up and shutdown of the audit function is not being audited. 5.1.2 FAU_GEN.2 User identity association FAU_GEN.2.1 The TSF shall be able to associate each auditable event with the identity of the user that caused the event. Application Note: The unauthenticated or anonymous users will be assigned the unauthenticated or anonymous user identify. 5.1.3 FAU_SAR.1 Audit review FAU_SAR.1.1 The TSF shall provide the Directory Administrator and the Members of the Administrative Group with the capability to read all audit information from the audit records. FAU_SAR.1.2 The TSF shall provide the audit records in a manner suitable for the user to interpret the information. 5.1.4 FAU_SAR.2 Restricted audit review FAU_SAR.2.1 The TSF shall prohibit all users read access to the audit records, except those users that have been granted explicit read-write-access. Application Note: Directory Administrator has read-write-access. The Administrative Group Members have read access for the audit records, and there is nothing preventing the Administrative Group Members also from erasing the audit records. No other users have any access to the audit records. 5.1.5 FDP_ACC.2 Complete access control FDP_ACC.2.1 The TSF shall enforce the Directory Access Control SFP on users as subjects and directory entries and attributes as objects and all operations among subjects and objects covered by the SFP. Copyright IBM 2003 PAGE 17 IBM Tivoli Directory Server Version 5.2 FDP_ACC.2.2 The TSF shall ensure that all operations between any subject in the TSC and any object within the TSC are covered by an access control SFP. Application Note: Access rights may be attached to users, groups and roles. Subjects that can access directory entries or attributes are users, but the decision if to grant the requested access takes the user’s membership in groups and the user’s role into account. For proxied authorization, the user assumes the proxied identity and the ACL restrictions for the proxied identity. It is not possible to gain the rights of administrator or members of the administrative group by using proxied authorization. 5.1.6 FDP_ACF.1 Security attribute based access control FDP_ACF.1.1 The TSF shall enforce the Directory Access Control SFP to objects based on two attributes sets: 1. Entry Owner Information: o entryOwner: defines entry owner. o ownerPropagate: indicates whether to propagate the ownership of the entry to all descendant entries. 2. Access Control Information (ACI) o Non-filter based aclEntry: defines the access control information. aclPropagate: indicates whether to propagate access control information of the entry to all descendant entries. o Filter based ibm-filterAclEntry: defines filter-based access control information. ibm-filterAclInherit: indicates whether to terminate accumulation of access control information. FDP_ACF.1.2 The TSF shall enforce the following rule to determine if an operation among controlled subjects and controlled objects is allowed in the following evaluation order: 1. By comparing the subject’s bind DN with the effective entryOwner attribute values. The entry owner has full access to the target entry. 2. If the subject does not possess the entry ownership, the check for access continues by comparing the subject’s DN with the effective ACI of the target entry. Depending on the ACI type two access control modes are possible: I. In non filter-based ACL this means matching the subject DN with the subject of the ACI information. If a match on the subject is found the permissions defined in the corresponding ACI are enforced. II. In filter-based ACL this means matching the subject DN and the requested object, with the subject and object of the ACI information. If a match on both the subject and the object is found the permissions defined in the corresponding ACI are enforced. 3. If no ACI information is found for the target object either explicitly or through inheritance, then default access is given. Application Note: The Directory Administrator and Administration Group Members are the entryOwners for all objects in the directory by default, and this entryOwnership can Copyright IBM 2003 PAGE 18 IBM Tivoli Directory Server Version 5.2 not be removed from any object. For proxied authorization, the user assumes the proxied identity and the ACL restrictions for the proxied identity. It is not possible to gain the rights of administrator or members of the administrative group by using proxied authorization. FDP_ACF.1.3 The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: any subject may be allowed access to public information. Application Note: Anonymous users may only have access to public information if the Directory Administrator configured anonymous binds to the TOE to be allowed. FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the: none. Application Note: Section 6.1.2 defines the rather complex rules for access control. A later version of this Security Target may try to express those rules in FDP_ACF.1. 5.1.7 FIA_AFL.1 Authentication failure handling FIA_AFL.1.1 The TSF shall detect when 3 unsuccessful authentication attempts occur related to consecutive authentication attempts of the same End User. FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been met or surpassed, the TSF shall prohibit further login of that End User until the Directory Administrator or a Member of the Administrative Group has reset that End User’s password. Application Note: The number of unsuccessful authentication attempts can be specified by the Directory Administrator or a Member of the Administrative Group. The value of three is the one selected for the secure configuration. The authentication failure handling applies to all End Users, but not to the Directory Administrator or to the Members of the Administrative Group. 5.1.8 FIA_ATD.1 User attribute definition FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to individual users: Distinguished Name of the user • • • • • • userPassword: it specifies the user’s password pwdChangedTime: it specifies the last time the user’s password was changed pwdFailureTime: it holds the times of the consecutive authentication failures, which are internally maintained by the directory. pwdAccountLockedTime: it holds the time that the user’s account was locked pwdReset: it holds a flag to indicate whether the user password has been reset and therefore must be changed by the user on next authentication Application Note: In addition to these attributes, there are several other user attributes, which are not considered to be security attributes. All these attributes are maintained for End Users. None of the attributes above, with the exception of the Distinguished Name and the Copyright IBM 2003 PAGE 19 IBM Tivoli Directory Server Version 5.2 userPassword, are maintained for the Directory Administrator or for the Members of the Administrative Group. 5.1.9 FIA_SOS.1 Verification of secrets FIA_SOS.1.1 The TSF shall provide a mechanism to verify that secrets meet the password policy constraints, defined by the following attributes: • Minimum length of 8 characters • Minimum number of 2 non-alphabetic characters • Minimum of 4 alphabetic characters • Maximum of 2 identical characters • Maximum age of 90 days • Minimum time of 1 day to expire before a password can be changed again Application Note: The Directory Administrator and Members of the Administrative Group have the ability to specify different values than those listed above. The above listed values are those that are considered for a secure configuration. The claimed SOF for the authentication mechanism is SOF-basic. This claim is based on the setting above for the verification of secrets. The Directory Administrator or Members of the Administrative Group passwords are not subject to the constraints of the password policy. 5.1.10 FIA_UAU.1 Timing of authentication FIA_UAU.1.1 The TSF shall allow limited operations as assigned by the Directory Administrator and Members of the Administrative Group in compliance with the security policy on behalf of the user to be performed before the user is authenticated. FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. Application Note: The Directory Administrator and the Members of the Administrative Group may allow unauthenticated users to perform search, add, modify, compare and extended operations on public information, without a previous authentication. The bind/unbind is part of the user authentication and abandon is an allowed operation also for unauthenticated users. 5.1.11 FIA_UID.1 Timing of identification FIA_UID.1.1 The TSF shall allow limited operations as assigned by the Directory Administrator and Members of the Administrative Group in compliance with the security policy on behalf of the user to be performed before the user is identified. FIA_UID.1.2 The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user. Application Note: The note for FIA_UAU.1 also applies for the identification since this is performed as one bind operation. 5.1.12 FMT_MOF.1a Management of security functions behaviour FMT_MOF.1.1 The TSF shall restrict the ability to modify the behaviour of the functions: authentication mechanism to the Directory Administrator and the Members of the Administrative Group. Copyright IBM 2003 PAGE 20 IBM Tivoli Directory Server Version 5.2 5.1.13 FMT_MOF.1b Management of security functions behaviour FMT_MOF.1.1 The TSF shall restrict the ability to disable, enable, and modify the behaviour of the functions audit service to the Directory Administrator. 5.1.14 FMT_MSA.1 Management of security attributes FMT_MSA.1.1 The TSF shall enforce the Directory Access Control SFP to restrict the ability to modify, delete, or read the security attributes: a) Password – User (account owner), Members of the Administrative Group or Directory Administrator b) Password policy – The attributes of the password policy for the whole directory can be read by everybody, but only changed by the Directory Administrator. c) Entry Owner Information – End User (entry owner) or Directory Administrator d) Access Control Information – End User (entry owner) or Directory Administrator e) Audit options – Directory Administrator to those users or roles as identified above. Application Note: The Members of the Administrative Group cannot modify the password of the Directory Administrator or other Members of the Administrative Group. The passwords cannot be read as clear text, since they are stored as in an encrypted form in the evaluated configuration of the TOE. 5.1.15 FMT_MSA.3 Static attribute initialisation FMT_MSA.3.1 The TSF shall enforce the Directory Access Control SFP to provide restrictive default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2 The TSF shall allow the Directory Administrator, the Members of the Administrative Group or authorized End Users with roles of proper privileges to specify alternative initial values to override the default values when an object or information is created. 5.1.16 FMT_MTD.1 Management of TSF data FMT_MTD.1.1 The TSF shall restrict the ability to modify the TOE security configuration made in the schema file and in the configuration file to the Directory Administrator. 5.1.17 FMT_SMF.1 Specification of Management Functions FMT_SMF.1.1 The TSF shall be capable of performing the following security management functions: a) Password management b) Password policy management c) User management d) Access Control Management e) Audit management. Copyright IBM 2003 PAGE 21 IBM Tivoli Directory Server Version 5.2 5.1.18 FMT_SMR.1 Security roles FMT_SMR.1.1 The TSF shall maintain the roles Directory Administrator, Member of the Administrative Group and End User. FMT_SMR.1.2 The TSF shall be able to associate users with roles. 5.1.19 FPT_RVM.1 Non-bypassability of the TSP FPT_RVM.1.1 The TSF shall ensure that TSP enforcement functions are invoked and succeed before each function within the TSC is allowed to proceed. 5.2 TOE Environment SecurityFunctional Requirements This section identifies and specifies the environmental SFR components that the environment of the TOE is intended to meet for the purposes of this CC evaluation. All of these SFR components are chosen to directly or indirectly (i.e., via a functional component dependency) satisfy the environmental security objectives for the TOE. IT Security Requirements for the underlying Operating System 5.2.1 FPT_STM.1 Reliable time stamps FPT_STM.1.1 The TSF shall be able to provide reliable time stamps for its own use. Non-IT Security Requirements for the TOE Environment The following requirements for the non-IT environment of the TOE need to be satisfied: ER.ATTACK – Sophisticated Attacks The TOE as well as the database needs to be protected against sophisticated attacks by appropriate measures in the TOE environment if such protection is required by the operational policy. This includes also potential denial-of-service attacks when the functions of the TOE are used for time critical applications. Note that this requirement may be satisfied by physical / organizational controls, IT controls or a combination of both. This Security Target does not prescribe how the required protection is achieved. ER.BACKUP – Backup and Recovery Backup of the TSF data and the TOE user data have to be taken which allow to restore the TOE with its TSF data and user data in a known and secure state. Backup frequency and strategy must be defined in the security policy of the organization responsible for the operation of the TOE. Backup data needs to be adequately protected to prevent loss, unauthorized access or modification. ER.COMMUNICATION – Protection of the Communication Communication links between the TOE and LDAP clients on external systems need to guarantee the authenticity of the communication partner and need to be protected from unauthorized access to and modification of communication data. ER.OS-MANAGE – Management of the Operating System Environment Copyright IBM 2003 PAGE 22 IBM Tivoli Directory Server Version 5.2 The operating system and hardware used to run the TOE on must be configured and managed by competent and trustworthy personnel in a way that ensures the security, preventing unauthorized access to the TOE, TSF data and user data. Note that this requirement may be satisfied by physical / organizational controls, IT controls, or a combination of both. This Security Target does not prescribe how the required protection is achieved. ER.MANAGE – Management of the TOE The TOE must be installed and managed by competent and trustworthy personnel in a way that ensures the security, preventing unauthorized access to the TOE, the TSF data and user data. ER.DATABASE – Management of the Database The database used to store the TSF and user data must be protected from unauthorized access, tampering and loss of data. The database must be configured and managed by competent and trustworthy personnel to ensure this protection at all operational stages. 5.3 TOESecurityAssuranceRequirements The security assurance requirements for EAL 3, as specified in Part 3 of the CC, are summarized in the following table: Table 2: TOE assurance components Component Component ID Component Title ACM_CAP.3 Authorisation controls Configuration management ACM_SCP.1 TOE Cm coverage ADO_DEL.1 Delivery procedures Delivery and operation ADO_IGS.1 Installation, generation, and start-up procedures ADV_FSP.1 Informal functional specification ADV_HLD.2 Security enforcing high-level design Development ADV_RCR.1 Informal correspondence demonstration AGD_ADM.1 Administrator guidance Guidance documents AGD_USR.1 User guidance Life cycle support ALC_DVS.1 Identification of security measures ATE_COV.2 Analysis of coverage ATE_DPT.1 Testing: high-level design ATE_FUN.1 Functional Testing Tests ATE_IND.2 Independent testing – sample AVA_MSU.1 Examination of guidance AVA_SOF.1 Strength of TOE security function evaluation Vulnerability assessment AVA_VLA.1 Developer vulnerability analysis Copyright IBM 2003 PAGE 23 IBM Tivoli Directory Server Version 5.2 6 TOE Summary Specification This section provides a description of the TOE security functions and assurance measures, which meet the TOE security requirements specified in Section 5. 6.1 TOE SecurityFunctions The TOE security functions are described as follows: 6.1.1 F.AUDIT The TOE provides audit generation service; the server and the administration daemon each have an audit log file and an error log file. In the audit log file audit entries are written in chronological order to keep traces of users’ activities and to keep track of any changes made to the audit function. The audit service also generates error messages into the error log file. The audit log file, admin daemon log file and error log file entries are stored as text files, which are managed and reviewed using the audit review as part of F.MANAGEMENT.4. 6.1.1.1 Audit Generation (F.AUDIT.1) The audit service will generate at least one audit log entry for each valid LDAP request received by the server. The entry is generated when the server is about to return the corresponding LDAP response to the client, i.e., when the result of the processing is known. There are two versions of the audit function that can be selected by the Directory Administrator, version 1 or 2. Only version 2 is considered for the evaluated configuration, since only version 2 is able to audit extended operations. In addition to the LDAP audit events, audit events are also generated by the audit service for starting or stopping of the Audit Service, or any changes made of the audit configuration options. These messages will be logged in the audit log as well as in the error log. This is to cover the case that the audit log is full and no more entries could be added. The audit log will grow and requires the Directory Administrator to manage (delete, save, or replace) the content of the audit log (as part of the TOE environment). In case the server is not able to write to the audit log file, i.e. the device is out of space, an error message will be written in the error log file; the ITDS will continue to operate, but the auditing function will no longer generate audit entries into the audit log file. To accurately track a user’s activity, each message entry contains the following information: • time when the activity occurs, • the user’s identity or unauthenticated and anonymous for unauthenticated and anonymous users respectively, • the activity, and • the result of the activity. The format of each message entry will be: AuditV2 -- Timestamp1 -- message text Each non-message entry will contain a header (general information) and operation specific data. The header will be in the following format: AuditV2 -- Timestamp1 -- Version number + [TLS] [SSL] + [unauthenticated or anonymous] Operation—bindDN: server encoded DN string -- client:Client IP address:Port number -- Copyright IBM 2003 PAGE 24 IBM Tivoli Directory Server Version 5.2 ConnectionID: xxxx -- received: Timestamp2 -- Result or Status string Where: Timestamp 1 Is the local time the entry is logged (i.e., when the processing of the request is done). Version number +[SSL]+[unauthenticated or anonymous] Operation Shows the LDAP request that was received and processed. Version number is either V2 or V3. SSL indicates whether SSL was used. The SSL within the brackets will show if SSL was used or not. Unauthenticated indicates whether the request was sent by an anonymous or unauthenticated client. If the client was anonymous or unauthenticated the text “authenticated” or “anonymous” will be shown before the Operation. For authenticated requests, this will be omitted and the bindDN user ID will be shown as described below. bindDN: server encoded DN string Shows the bind DN. The encoding done by the server is to hide the DN from trivial viewing. The server will provide a decoding function through an LDAP search of special audit related attributes. For V3 unauthenticated or anonymous requests, this field will not be shown. client:Client IP address:Port number Shows the client’s IP address and port number. ConnectionID: xxxx Shows the connection identification number used to tie all the entries of a connection together (i.e. all events between a Bind and an Unbind). received: Timestamp 2 Is the local time when the request was received, or more precisely, the beginning time when the request was processed. Its format is the same as Timestamp 1. Result or Status Shows the result or status of the LDAP operation. The result is a text message like “success” or “operationsError”. For the LDAP operation a message will follow the header and display the operation specific data of that LDAP operation. The following lists the operation specific data for each auditable operation. The following information is associated with the individual operations: Bind name – the DN of the client authenticating to the server; authenticationChoice – the authentication choice (simple authentication, sasl or Kerberos, but only simple is part of the evaluation); authenticationMechanism – the authentication mechanisms used, but only in case a SASL mechanisms is being used (which is not considered part of the evaluated configuration). Unbind No operation specific data. Search base – the base DN for the search; scope – the scope of the search; derefAliases – the dereferencing option supplied by the client indicating how aliases dereferencing should be done in the request (either never, always, when searching, or dereferenced only when locating the base object for the search); typesOnly – a Boolean flag indicating whether the client wants to have the attribute types and values, or the attributes types only; filter – the filter string used for the search Copyright IBM 2003 PAGE 25 IBM Tivoli Directory Server Version 5.2 request; attributes – and finally the list of all attributes that are requested, provided they are specified by the client in the search request. Add entry – the DN that is added to the DIT (directory information tree); attributes – the list of attributes the added attribute contains. Modify object – the DN of the entry subject to modification; operation – and the operation type (add, delete or replace) and attribute subject to the operation. This entry is repeated for each operation/attribute pair affected by the request from the client. Delete entry - the DN of the entry requested to be being deleted. ModifyDN (for LDAP v2, this is called ModifyRDN) entry – the DN of the entry subject to renaming; newrdn - the new DN after the renaming; deleteoldrdn – a Boolean value indicating if the old DN is being deleted (or copied); newSuperior – the name of the new parent DN for the new entry. Event notification extended operation: registration eventID – the event notification ID created by the server during registration; base – the base entry containing the baseDN, at which the notification starts in the DIT (directory information tree); scope – the cope of the operation; type – the type of event for which the client is requesting event notification. Event notification extended operation: unregister eventID – the event notification ID created by the server during registration. Extended operation (with exception of event notification) OID – the OID value for the extended operation. 6.1.2 F.ACCESS_CONTROL Permission to perform a particular LDAP operation on a specified target object is granted or denied based on the subject’s DN (Distinguished Name), established by the bind operation. Users, who have not performed a bind or an anonymous bind, will have an empty DN (NullDN) and are called unauthenticated or anonymous. There is no difference between the access rights given to unauthenticated and anonymous user. In addition to the authorization given to users based on the subjects DN, users may also be given proxied authorisation by becoming a member of a proxied authorization group. The members in the proxied authorization group can assume any authenticated identities in the group except the Directory Administrator or Members of Administrative Group. The proxied authorization control for specifying an authorization identity is on per LDAP operation basis instead of whole LDAP session basis. To use proxied authorization, user being a member of a proxied authorization group will have to pass control data along with LDAP request, stating the proxied DN which will be the subject DN under which the operation will be performed. The members in the proxied authorization group can assume any identities in the proxied authorization group, except administrator or members in administrative group. Administrator or members in the administrative group will be granted proxied authorization right by default, without explicitly being a member of a proxied authorization group. Each entry within the LDAP directory contains the distinguished name of the entry as well as a set of attributes and their corresponding values. Each entry has a list of entry owners kept in the attribute entryOwner. In addition each entry has a set of associated ACIs (Access Copyright IBM 2003 PAGE 26 IBM Tivoli Directory Server Version 5.2 Control Information). When determining access, the entryOwner information and the ACI information are being used. The access control using the ACI information is either filter-based or non filter-based. The attributes are mutually exclusive within a single containing directory entry. However, both types can co-exist in the directory tree in separate entries. The ACI type of the target entry ACI determines the mode of calculation. In filter based mode, non-filter based ACLs are ignored in effective access calculation, and vice versa. The ACIs for an entry is determined in the following way: a) If there is a set of explicit access control attributes at the entry, then the entry’s ACI applies. b) If there is no explicitly defined access control attributes, then traverse the directory tree upwards until an ancestor node is reached with a set of propagating access control attributes. c) If no such ancestor node is found, the default access rights will apply. The default access rights are predefined and cannot be changed by the Directory Administrator. It is possible to grant access to groups by associate multiple subject DNs to DNs representing a group. The LDAP server also maintains dynamic groups called pseudo DNs. These group DNs can be granted rights, which will apply to all group members. The ACI information applicable to an entry is compiled and used in the following way: 1. Specificity Rule a) The rights assigned to the owner DN dominate over the right of the group DN. b) Within the same entry, individual attribute permissions dominate over the attribute class permissions. c) Within the same attribute or attribute class, deny dominates over grant. 2. Combinatory Rule o For each entry the permissions granted to subjects of equal importance, as described under a), b) and c) above are combined. o If the access cannot be determined within the same specificity level, the access definitions of a less specific level are used. o If the access is not determined after defined ACIs are applied, the access is denied. 6.1.2.1 Order of Evaluation When determine access, processing stops as soon as access can be determined based on access evaluation order, evaluation mode and evaluation rules as described below: 1. The first check for access is done by comparing the subject’s bind DN with the effective entryOwner attribute values. The entry owner has full access to the target entry. The Directory Administrator is always the owner of all entries in the directory tree. 2. If the subject does not possess the entry ownership, the check for access continues by comparing the subject’s DN with the effective ACI of the target entry. Depending on the ACI type two access control modes are possible: i. In non filter-based ACL this means matching the subject DN with the subject of the ACI information. If a match on the subject is found the permissions defined in the corresponding ACI are enforced. Copyright IBM 2003 PAGE 27 IBM Tivoli Directory Server Version 5.2 ii. In filter-based ACL this means matching the subject DN and the requested object, with the subject and object of the ACI information. If a match on both the subject and the object is found the permissions defined in the corresponding ACI are enforced. 3. If no ACI information is found for the target object either explicitly or through inheritance, then default access is given. 6.1.2.2 Access Control Attributes The TOE controls access to all directory entry objects based on the following security attributes: • Entry Owner Information o entryOwner – identifying the DN of the owner of the entry o ownerPropagate – specifying the inheritance of ownership in case no entry owner is specified in descendants • Access Control Information (ACI) o non filter-based aclEntry – specifying the access control for the non filter-based ACI aclPropagate – specifying the inheritance of access control rights in case no ACI is specified in descendants o filter-based ibm-filterAclEntry – specifying the access control for the filter-based ACI ibm-filterAclInherit – specifying the inheritance of access control rights in case no ACI is specified in descendants • Groups and roles 6.1.3 F.I&A 6.1.3.1 User Authentication (F.I&A.1) In order to give the users access rights to other than operations on public data, the TOE requires each user to be successfully identified and authenticated. The subject’s DN is established by the identification and authentication using a bind operation. The TOE uses a simple user ID / password authentication method to authenticate users as defined in RFC 2251. Users are maintained in the directory. The behavior of the authentication mechanism is controlled by the password policy specified by the Directory Administrator (see F.MANAGEMENT.2 below). The administrator can also specify that a user has to change his password after it has been initially set or after it has been reset by the administrator. The administrator can also define the number of consecutive failed authentication attempts after which the following happens: • the user will not be able to log in until the administrator has reset the user’s password Copyright IBM 2003 PAGE 28 IBM Tivoli Directory Server Version 5.2 6.1.4 F.MANAGEMENT The TOE allows the Directory Administrators to manage the behavior of the following functions: • Authentication function • Authorization function • Audit function The TOE allows Directory Administrators to configure the following security attributes: • Password policy (Authentication function) • Entry Owner Information (Authorization function) • Access Control Information (Authorization function) • Audit options (Audit function) 6.1.4.1 Roles (F.MANAGEMENT.1) The TOE supports three security roles: Directory Administrator, Administrative Group Member and End User. All three roles are defined within the TOE. While the ordinary End Users have no administrative rights, the Directory Administrator has the ability to define groups and other “roles” to assist in the management of access rights and privileges. Those administrator defined groups and roles are not considered to be roles in the sense of the CC requirement FMT_SMR.1 but are just ways to manage access rights more easily. The Directory Administrator also has the ability to define Members of the Administrative Group, which will have a limited set of the administrative rights of the Directory Administrator. The administrative rights can be divided into two categories, ability to make changes to the configuration of the TOE and ability to perform certain extended operations. The Members of the Administrative Group has the same rights as the Directory Administrator with the difference that they cannot make configuration changes to the administrative group (cn=admingroup, cn=configuration), auditing (cn=audit, cn=configuration) or to change the DN or password of the Directory Administrator. The Members of the Administrative Group also cannot perform some extended operations (see table below). Extended operation, Short name, description and OID Directory Administrator Administrative Group Member End User Event Registration - Request Request registration for events in SecureWay V3.2 Event support. OID = 1.3.18.0.2.12.1 Yes Yes Yes Event Unregister - Request Unregister for events that were registered for using an Event Registration Request. OID = 1.3.18.0.2.12.3 Yes Yes Yes Begin Transaction - Begin a Transactional context for SecureWay V3.2 OID = 1.3.18.0.2.12.5 Yes Yes Yes End Transaction - End Transactional context (commit/rollback) for SecureWay V3.2 OID = 1.3.18.0.2.12.6 Yes Yes Yes Cascading Control - Replication This operation performs the requested action on the server it is issued to and cascades the call to all consumers beneath it in the Yes Yes -- Copyright IBM 2003 PAGE 29 IBM Tivoli Directory Server Version 5.2 Extended operation, Short name, description and OID Directory Administrator Administrative Group Member End User replication topology. OID = 1.3.18.0.2.12.15 Control Replication = This operation is used to force immediate replication, suspend replication, or resume replication by a supplier. This operation is allowed only when the client has update authority to the replication agreement. OID = 1.3.18.0.2.12.16 Yes Yes -- Control Replication Queue - This operation marks items as "already replicated" for a specified agreement. This operation is allowed only when the client has update authority to the replication agreement. OID = 1.3.18.0.2.12.17 Yes Yes -- Quiesce or Unquiesce Server - This operation puts the subtree into a state where it does not accept client updates (or terminates this state), except for updates from clients authenticated as directory administrators where the Server Administration control is present. OID = 1.3.18.0.2.12.19 Yes Yes -- Clear Log Request - Request to Clear log file. OID = 1.3.18.0.2.12.20 Yes Note 1 -- Get Lines Request - Request to get lines from a log file. OID = 1.3.18.0.2.12.22 Yes Yes -- Number of Lines Request - Request number of lines in a log file. OID = 1.3.18.0.2.12.24 Yes Yes -- Start, Stop Server Request - Request to start, stop or restart an LDAP server. OID = 1.3.18.0.2.12.26 Yes Yes -- Update Configuration Request - Request to update server configuration for IBM Directory Server. OID = 1.3.18.0.2.12.28 Yes Yes -- DN Normalization Request - Request to normalize a DN or a sequence of DNs. OID = 1.3.18.0.2.12.30 Yes Yes Yes Kill Connection Request - Request to kill connections on the server. The request can be to kill all connections or kill connections by bound DN, IP, or a bound DN from a particular IP. OID = 1.3.18.0.2.12.35 Yes Note 2 -- User Type Request - Request to get the User Type of the bound user. OID = 1.3.18.0.2.12.37 Yes Yes Yes Control Server - Tracing Activate or deactivate tracing in the IBM Directory Server. OID = 1.3.18.0.2.12.40 Yes Yes -- Start TLS - Request to start Transport Layer Security. OID = 1.3.6.1.4.1.1466.20037 Yes Yes Yes Enable and Disable Tracing Dynamically. OID = 1.3.18.0.2.32.14 Yes Yes -- Note 1: All log files, with the exception of the audit files for the server and administration daemon can be cleared using this extended operation, even if there is no security claim that the Members of the Administrative Group cannot erase the audit files for the server and administration. Note 2: Any connection can be killed, except connection associated with the Directory Administrator and Members of the Administrative Group. 6.1.4.2 Authentication Function (F.MANAGEMENT.2) The TOE has the following password criteria, called the password policy, that can be specified by the Directory Administrator or Members of the Administrative Group to enhance the quality of the passwords selected by the End Users: • Minimum length of passwords • Minimum number of alphabetic characters • Minimum number of non-alphabetic characters Copyright IBM 2003 PAGE 30 IBM Tivoli Directory Server Version 5.2 • Maximum number of repeated characters • Maximum lifetime of a password • Minimum lifetime of a password The Directory Administrator or Members of the Administrative Group a can also specify that a user has to change his password after it has been initially set or after it has been reset by the administrator. The Directory Administrator can also define the number of consecutive failed authentication attempts after which one of the following happens: • any further authentication attempt is prohibited for a time period defined by the administrator or • the user will not be able to log in until the administrator has reset the user’s password The Directory Administrator or Members of the Administrative Group can also specify if a user is allowed to change his own password. The following section defines the password security policy settings that are considered for the evaluated configuration: • pwdCheckSyntax – 1 (activate the password checking mechanism) • Minimum length of passwords (pwdMinLength) – default for secure configuration is 8 characters • Minimum number of alphabetic characters (passwordminalphachars) – default for secure configuration is 4 • Maximum number of repeated characters (passwordmaxrepeatedchars) – default for secure configuration is 2 • Minimum number of non-alphabetic characters (passwordMinOtherChars) – default for secure configuration is 2 • Maximum lifetime of a password (pwdMaxAge) – default for secure configuration is 90 days (7776000 seconds) • Minumum lifetime of a password (pwdMinAge) – default for secure configuration is 1 day (86400 seconds) • Maximum number of consecutive failed login attempts (PwdMaxFailure) – default for secure configuration is 3 • Action to be taken when PwdMaxFailure is reached or exceeded – default for secure configuration is: End User cannot log in until the administrator has reset the password (pwdLockout – TRUE and pwdLockoutDuration – 0) • End User must change his password after initialization and after reset by the Directory Administrator (pwdMustChange – TRUE) • End Users are allowed to change their own password (pwdAllowUserChange – TRUE) • pwdSafeModify – TRUE • ibm-pwdpolicy – TRUE Copyright IBM 2003 PAGE 31 IBM Tivoli Directory Server Version 5.2 6.1.4.3 Authorization Functions (F.MANAGEMENT.3) With the exception of the user password entry and the system attributes, the entry owners have full access rights for an entry and are able to use the authorization function to modify the authorization information on an entry. The Directory Administrator and Administration Group Members are the entryOwners for all objects in the directory by default, and this entryOwnership cannot be removed from any object. The following functions for management of security attributes are available: • Entry owner information – the entry owner information (entryOwner) of an entry can be set by the entry owner. This means that the entry owner can give away an entry to any other user. The entry owner information is either inherited from an ancestor or directly specified for each entry. • Access Control Information (ACI) – the access control information can be specified by the entry owner. This means that these users can specify explicit access rights by specifying the access control mode and the associated attributes. These are: o Non filter-based ACL – containing the aclEntry defining the access control information and aclPropagate indicating whether to propagate the ACL information to descendants. o Filter-based ACL – containing the ibm-filterAclEntry defining the filter- based access control information, and aclPropagate indicating whether to propagate the ACL information to descendants. There are attributes, so called system attributes that can only be changed by the system itself, and not be changed by neither any the End User nor by the Directory Administrator or the Members of the Administrative Group. E.g., the pwdChangedTime, specifying the last time the user’s password was changed. Changes to the user password entries are not only subject to the access control, as described above, but in addition subject the constrains of the password policy. 6.1.4.4 Audit Function (F.MANAGEMENT.4) The audit management is divided into management of the audit function and audit file management. The audit management is restricted to the Directory Administrator. Audit function management The directory administrator can perform the following management functions: • The audit subsystem can be enabled and disabled. • The audit file name can be specified. • The auditable events can separately be activated or deactivated for the following events: bind, unbind, search, add, modify, delete, modifyDN (including modifyRDN), the event notification extended operation: registration and unregistration • Select that only operations that failed are to be audited, or both failed and successful operations. Note: The modifyDN and modifyRDN are indistinguishable by the audit function such that they will both be audited as modifyDN and also cannot be configured individually. Copyright IBM 2003 PAGE 32 IBM Tivoli Directory Server Version 5.2 Audit file management There are three different extended operations available to the Directory Administrator for managing the log files. With the extended operation LDAP requests, the audit file can be queried, read or deleted as follows: • Request number of lines – inquiry of how many lines are in the log file • View request – request to view a subset of the log file • Clear request – request to clear the log file The LDAP server reads the lines of the log file and truncates a line down to 400 characters in case the line is larger before sending it to the client. This is set to prevent the server from sending endless lines. Each of the extended operation must contain at least the type of the requested log file. 6.1.5 F.REF_MEDIATION The TOE is designed such that all security policy enforcement functions are invoked and succeed before each function within the TSC is allowed to proceed. Any request for access to a directory entry the TOE receives is checked for access according to the rules defined for the TOE. 6.1.6 TOE Security Functions rationale For a justification of the TOE security functions to meet the security functional requirements is provided in TOE Security Functional Rationale, section 8.3.1. 6.2 AssuranceMeasures The assurance requirements for EAL 3 are met by this TOE by the following assurance measures. These assurance requirements provide, primarily via review of supplied evidence, independent confirmation that these actions have been competently performed. They also include the following independent, third-party analysis: a) Confirmation of effective configuration management b) Confirmation of product delivery and installation procedures c) Conformation of the life-cycle security in the development environment d) Confirmation that the guidance documentation is adequate e) Verification of a sample of the vendor functional testing f) Verification of the developers analysis for vulnerabilities and resistance against obvious penetration attacks g) Independent functional testing To define the assurance measures claimed to satisfy the security assurance requirements specified in Section 5.2, a mapping is provided between the Assurance Requirements and the Assurance Measures, which are intended to satisfy the Assurance Requirements. As shown in Table 3, the Assurance Measures are provided in the form of references to the relevant and appropriate document associated with each requirement. Table 3: Assurance Measures CC Assurance Component Assurance Measure ACM_CAP.3 - Authorisation controls M.CAP Configuration Management Version Control (CMVC) and Lotus team Copyright IBM 2003 PAGE 33 IBM Tivoli Directory Server Version 5.2 CC Assurance Component Assurance Measure rooms are used to manage configuration items of the TOE. ACM_SCP.1 - TOE CM coverage M.SCP In addition to the previous evaluation, all documentation will be under the control of the CMVC tool ADO_DEL.1 - Delivery procedures M.DEL The software will be delivered via the Internet using a secure download mechanism as defined in the Download Director Specification, as described in the previous evaluation. ADO_IGS.1 - Installation, generation, and start-up procedures M.IGS This process will be described in the document: IBM Tivoli Directory Server Version 5.2 Installation and Configuration Guide and in the IBM Tivoli Directory Server and in the Security Guide. ADV_FSP.1 - Informal functional specification M.FSP The functional specification will be provided in the document IBM Tivoli Directory Server Version 5.2 Functional Specification. ADV_HLD.2 - Security enforcing high-level design M.HLD The high level design will be described in the document IBM Tivoli Directory Server Version 5.2 High Level Design. ADV_RCR.1 - Informal correspondence demonstration M.RCR Correspondence demonstration will be provided in a separate document that maps the TOE Summary Specification to the Functional Specification and the Functional Specification to the High Level Design. AGD_ADM.1 - Administrator guidance M.ADM The administrator guidance will be provided with the IBM Tivoli Directory Server Version 5.2 Administration Guide AGD_USR.1 - User guidance M.USR The user guidance will be provided with the IBM Tivoli Directory Server Version 5.2: C-Client SDK Programming Reference ALC_DVS.1 - Identification of security measures M.DVS The security procedures on the development site are described in general documents that apply for IBM as a whole as well as site specific documents and specific documents for the LDAP development. ATE_COV.2 - Analysis of coverage M.COV Detailed test plans are produced to test the functions of the TOE. Those test plans include an analysis of the test coverage, an analysis of the functional interfaces tested and an analysis of the testing against the high- level design ATE_DPT.1 - Testing: high-level design See above ATE_FUN.1 - Functional testing M.FUN Testing will be performed on a range of platforms as defined by the ST. Test results are documented such that the test can be repeated. ATE_IND.2 - Independent testing – sample M.IND Independent testing will be performed by the evaluation facility Copyright IBM 2003 PAGE 34 IBM Tivoli Directory Server Version 5.2 CC Assurance Component Assurance Measure AVA_MSU.1 - Examination of guidance M.VLA The misuse analysis will be provided as an update to the vulnerability analysis made for the EAL2 evaluation. AVA_SOF.1 - Strength of TOE security function evaluation M.SOF A Strength of Functional analysis will be provided for the password mechanism, based on the Strength of Function Analysis made for EAL 2. AVA_VLA.1 - Developer vulnerability analysis M.VLA A vulnerability analysis will be provided that describes IBM’s approach to identify vulnerabilities of ITDS 5.2 as well as the results of the findings. Copyright IBM 2003 PAGE 35 IBM Tivoli Directory Server Version 5.2 7 Protection Profile Claims 7.1 PPReference This Security Target does not claim conformance with any Protection Profile that has been registered and / or evaluated. Copyright IBM 2003 PAGE 36 IBM Tivoli Directory Server Version 5.2 8 Rationale 8.1 SecurityObjectives Rationale Table 4 provides a mapping of TOE security objectives to threats and assumptions. Then it is followed by rationale of how each threat, assumption and organizational security policy is addressed by the corresponding security objectives. Table 4: Mapping of Security Objectives to Threats, Assumptions and Policies T.ENTRY T.ACCESS T.ACCOUNT T.BYPASS TE.SOPHISTICATED TE.USAGE TE.CRASH TE.PASS A.PHYSICAL A.NOEVIL A.ADMIN A.COMM A.COOP A.TIME P.PUBLIC O.AUTHENTICATE X X O.AUTHORIZE X X O.ACCOUNT X O.BYPASS X OE.MANAGE X X X X OE.OS-MANAGE X X X X OE.PHYSICAL X X OE.DATABASE X X X X X OE.SOPHISTICATED X OE.BACKUP X OE.COMMUNICATION X X OE.TIME X T.ENTRY O.AUTHENTICATE ensures that all users are identified and authenticated before being granted access to TOE mediated resources except for allowing unauthenticated users to perform some operations on public data, configured by administrators. The administrators may also configure the TOE to reject any anonymous or unauthenticated users. It prevents unauthenticated users from access to TOE resources and services. T.ACCESS O.AUTHORIZE provides the capability to specify and manage access rights to TOE resources and services. Thus it prevents any user from access to data or performing operations without proper permissions. Unauthorized access during communication and while stored in the external database needs to be ensured by measures in the TOE environment and are addressed by the objectives OE.DATABASE and OE.COMMUNICATION. Copyright IBM 2003 PAGE 37 IBM Tivoli Directory Server Version 5.2 T.ACCOUNT O.AUTHENTICATE ensures that all users are identified and authenticated before being granted access to the TOE mediated resources except for allowing unauthenticated users to perform some operations on public data. Such limited access to the TOE is configured by the administrators and should be compliant with the security policy of the organization responsible for the operation of the TOE. Based on the identity information, O.ACCOUNT enforces that any security related events can be further associated with those accountable for such activities. Note that unauthenticated users and anonymous users are granted limited access to public data. For those audit entries for activities performed by unauthenticated users or anonymous users, no identity information is kept in such entries. The administrators may also configure the TOE to reject any anonymous or unauthenticated users. The two objectives together prevent security relevant actions from occurring without traceability of those accountable for such actions. T.BYPASS O.BYPASS enforces that the TOE security policy enforcement functions must always be invoked and succeed before access to TOE objects and services are allowed. It prevents the user from circumventing the TOE security functions. TE.SOPHISTICATED OE. SOPHISTICATED ensures that the TOE environment have sufficient capabilities to counter the threat of illegal users gaining unauthorized access via sophisticated attacking tools applied to the underlying system. TE.USAGE OE.MANAGE and OE.OS-MANAGE require that those responsible for the TOE must ensure that TOE is delivered, installed, operated, and administered in a secure manner. They address the threat introduced by misuse, misconfiguration, and mismanagement. This threat is also addressed by OE.DATABASE, which requires proper configuration and operation of the database system, which is part of the TOE environment. TE.CRASH OE.BACKUP requires that TOE environment have the backup services. Hence, upon human error, software/hardware failure, etc. which result in data loss or corruption, the system is still able to restore to a previous secure state. TE.PASS OE.PHYSICAL, OE.OS-MANAGE and OE.DATABASE requires that the hardware and software is physically protected, that the underlying operating system and hardware is configured and managed in a secure manner and that the database is configured and managed in a secure way, preventing the bypassing of the TOE security functions. A.PHYSICAL OE.PHYSICAL requires that TOE and its underlying hardware and software are physically protected from unauthorized physical modification and from technical attacks at the hardware and operating system level. Hence, this assumption is maintained. A.NOEVIL OE.MANAGE, OE.OS-MANAGE and OE.DATABASE require that TOE and the TOE environment is managed and administered in a secure manner. Assuming that the administrators should be trusted to perform discretionary actions in accordance with security policies. Copyright IBM 2003 PAGE 38 IBM Tivoli Directory Server Version 5.2 A.ADMIN OE.MANAGE, OE.OS-MANAGE and OE.DATABASE requires that TOE and the underlying OS and HW, and database is managed and administered in a secure manner, which implies that TOE and TOE environment are competently installed and administered. A.COMM OE.COMMUNICATION requires that communication links between the TOE and LDAP clients on external systems are protected to against unauthorized modification and disclosure of communication data. A.COOP OE.MANAGE requires that the TOE is managed in a secure manned to maintain the security of the TSF data and user data. Including the protection of user passwords and setting of the access control rights under the control of the individual users. A.TIME OE.TIME requires that the TOE environment provides a reliable time function. P.PUBLIC O.AUTHORIZE provides the capability to specify and manage the access rights to TOE resources and services. Thus, preventing users from access to data or performing operations without proper permissions by only making public information available to any user. 8.2 SecurityRequirements Rationale 8.2.1 Security Functional Requirements Rationale Table 5 shows a mapping of Security Functional Requirements to TOE Security Objectives and Security Objectives for the TOE environment. Following such a mapping, further discussion is given on how each Security Objective is addressed by the corresponding Security Functional Requirements. The italic text used in the table represents those functional components that are met by the TOE environment. Table 5: Mapping of Security Functional Requirements to TOE Security Objectives O.AUTHENTICATE O.AUTHORIZE O.ACCOUNT O.BYPASS OE.MANAGE OE.OS-MANAGE OE.PHYSICAL OE.DATABASE OE.SOPHISTICATED OE.BACKUP OE.COMMUNICATION OE.TIME FAU_GEN.1 X FAU_GEN.2 X FAU_SAR.1 X FAU_SAR.2 X FDP_ACC.2 X FDP_ACF.1 X FIA_AFL.1 X FIA_ATD.1 X Copyright IBM 2003 PAGE 39 IBM Tivoli Directory Server Version 5.2 O.AUTHENTICATE O.AUTHORIZE O.ACCOUNT O.BYPASS OE.MANAGE OE.OS-MANAGE OE.PHYSICAL OE.DATABASE OE.SOPHISTICATED OE.BACKUP OE.COMMUNICATION OE.TIME FIA_SOS.1 X FIA_UAU.1 X FIA_UID.1 X FMT_MOF.1a X X FMT_MOF.1b X FMT_MSA.1 X FMT_MSA.3 X FMT_MTD.1 X FMT_SMF.1 X X X FMT_SMR.1 X FPT_RVM.1 X FPT_STM.1 X X O.AUTHENTICATE FIA_AFL.1 ensures that an attacker does not have an unlimited number of authentication attempts he could use to guess an end user’s password. FIA.UID.1 ensures that, except that unauthenticated users and anonymous users are allowed access to public information and services configured by the Directory Administrator or Members of the Administrative Group in accordance with security policies, each user is successfully identified before allowing any TSF- mediated actions for that user. FIA_UAU.1 ensures that, except that unauthenticated users and anonymous users are allowed access to public information and services configured by the Directory Administrator or Members of the Administrative Group in accordance to security policies, each user is successfully authenticated before allowing any TSF- mediated actions for that user. FIA_SOS.1 ensures that password rules, for password based identification and authenticated, are enforced against all end users, preventing the bypassing or circumventing security policies. FMT_MOF.1a ensures that the authentication function is managed by the Directory Administrator or Members of the Administrative Group to enforce the appropriate password rules. FMT_SMF.1 ensures that the TSF is capable of performing management of the authentication function by password management and password policy management. Such security requirements work together to ensure successful Copyright IBM 2003 PAGE 40 IBM Tivoli Directory Server Version 5.2 identification and authentication prior to any TSF-mediated actions for each user. O.AUTHORIZE FDP_ACC.2 ensures that complete access control is enforced on access to TOE resources and services. FDP_ACF.1 ensures that the access control security policy is actually implemented by relevant security functions, based on user security attributes. FIA_ATD.1 ensures that user security attributes are maintained and managed by the TOE to provide supports for access control. FMT_MOF.1a ensures that the TSF behavior is administered and managed by the administrators, so that any change to it is restricted to authorized users. FMT_MSA.1 ensures that the TOE security attributes can only be administered and managed by the administrators authorized users. FMT_MSA.3 ensures that TOE assess control is enforced to restrict the capability to specify default security attributes to authorized users. FMT_MTD.1 ensures that access to TSF data is restricted to the Directory Administrator only. FMT_SMF.1 ensures that the TSF is capable of performing management of the users and of the access control. FMT_SMR.1 ensures that roles/groups are maintained by the TOE and can be associated with users to facilitate the access control. Such security requirements work together to ensure full control and management of user, data, and services, providing authorized user access to resources and functionality. O.ACCOUNT FAU_GEN.1 ensures that audit log of security related activity and events are recorded. FAU_GEN.2, which is a security requirement on TOE environment, ensures that each audit event can be associated with the identity of the user that caused the event so that the user can be held accountable for security related action, except for unauthenticated user and anonymous user. However, since ability to bind and access to resources and services is defined by the Directory Administrator and the Members of the Administrative Group in accordance to security policy, it doesn’t pose threats to TOE. FPT_STM.1, which is a security requirement on TOE environment, ensures that each audit entry is associated with reliable time stamp. Note that this time stamp is taken from the underlying operating system, which is part of the TOE environment. FAU_SAR.1 provides the Directory Administrator and the Members of the Administrative Group with the capability to review audit log. FAU_SAR.2 restricts the read access to the audit log to users of Directory Administrator role and Members of the Administrative Group. It further prevents any other users from manipulating the Copyright IBM 2003 PAGE 41 IBM Tivoli Directory Server Version 5.2 audit log and thereby preserves the integrity audit log. FMT_MOF.1b ensures that the behavior of the audit function is managed by the Directory Administrator to enforce accountability. Such security requirements, as a whole, ensure that users can be held accountable for their actions. FMT_SMF.1 ensures that the TSF is capable of performing management of the audit function. O.BYPASS FPT_RVM.1 ensures that security policy enforcement functions are invoked and succeed before each function is allowed to proceed so the access control is always enforced. These security requirements work together to prevent from bypassing and circumvention of TOE security policy. Note that, although unauthenticated user and anonymous user have limited access to TOE resources and services, such access is defined by the administrators and are under control by TOE security policy, hence it is not regarded as circumvention of security policy. OE.MANAGE No dependency to any SFR. OE.OS-MANAGE No dependency to any SFR. OE.PHYSICAL No dependency to any SFR. OE.DATABASE No dependency to any SFR. OE.SOPHISTICATED No dependency to any SFR. OE.BACKUP No dependency to any SFR. OE.COMMUNICATION No dependency to any SFR. OE.TIME FPT_STM.1 ensures that a reliable timestamp is provided by the TOE environment. 8.2.2 Dependency analysis Table 6 demonstrates that the security functional requirements meet all functional dependencies. The italic text used in the table represents those functional components that are met by the TOE environment. As the assurance components are those standard ones for EAL 3, all dependencies for such EAL 3 assurance components are satisfied automatically. Table 6: Dependency Mapping of Security Functional Requirements Component Name Dependencies FAU_GEN.1 Audit data generation FPT_STM.1 FAU_GEN.2 User identity generation FAU_GEN.1, FIA_UID.1 FAU_SAR.1 Audit review FAU_GEN.1 FAU_SAR.2 Restricted audit review FAU_SAR.1 FPT_STM.1 Time stamps — FDP_ACC.2 Complete access control FDP_ACF.1 FDP_ACF.1 Security attribute based access control FDP_ACC.1, FMT_MSA.3 Copyright IBM 2003 PAGE 42 IBM Tivoli Directory Server Version 5.2 Component Name Dependencies FIA_AFL.1 Authentication failure handling FIA_UAU.1 FIA_ATD.1 User attribute definition — FIA_SOS.1 Selection of secrets — FIA_UAU.1 Timing of authentication FIA_UID.1 FIA_UID.1 Timing of identification — FMT_MOF.1a Management of security functions behavior FMT_SMF.1, FMT_SMR.1 FMT_MOF.1b Management of security functions behavior FMT_SMF.1, FMT_SMR.1 FMT_MSA.1 Management of security attributes FDP_ACC.1 [or FDP_IFC.1] FMT_SMF.1, FMT_SMR.1 FMT_MSA.3 Static attribute initialization FMT_MSA.1, FMT_SMR.1 FMT_MTD.1 Management of TSF data FMT_SMF.1, FMT_SMR.1 FMT_SMF.1 Specification of Management Functions — FMT_SMR.1 Security roles FIA_UID.1 FPT_RVM.1 Non-bypassability of the TSP — 8.2.3 Demonstration of mutual support between security requirements The dependency analysis provided in the previous section has shown how supportive dependencies between SFRs are satisfied. This section further demonstrates that the SFRs are mutually supportive by highlighting and discussing the additional supportive dependencies, which ensures that security policies are enforced. FPT_RVM.1 ensures that SFRs cannot be bypassed. FIA_UAU.1 provides additional protection as it ensures that access to the TOE cannot be made by impersonate as a different user. FIA_UID.1 ensures that no security mediated functions can be initiated on behalf of a user until the user is uniquely identified to the TOE, except that limited access (to public information) is granted to unauthenticated user and anonymous user prior to identification and authentication. However, such restricted access is defined by Directory Administrators and Members of the Administrative Group in accordance to the organizational security policy. Then, it poses no threats to the TOE. FMT_SMR.1 enforces which roles users may take in the TOE and the conditions associated with assuming the role. Based on FMT_SMR.1, FMT_MOF.1a FMT_MOF.1b restricts the ability of users under specific roles to modify the behavior of functions that control security attributes or configuration data. With the aid of FMT_SMR.1, FMT_MSA.1 restricts the ability to modify security attributes or configuration data, protecting against tampering attacks through unauthorized modification of data. FMT_MSA.3 restricts default security attributes or configuration data controlled under FMT_MOF.1a, FMT_MOF.1b and FMT_MSA.1. FMT_MTD.1 restricts the ability to modify any other security relevant data, protecting against tampering attacks through unauthorized modification of data. FMT_FMF.1 specifies the management functions for the security behavior of the authentication function (FMT_MOF.1a) and for the password and password policy (FMT_MSA.1). FMT_FMF.1 also specifies the management functions for the user and access control (FMT_MSA.1 and FMT_MTD.1), as well as for the management of the audit function (FMT_MSA.1). Copyright IBM 2003 PAGE 43 IBM Tivoli Directory Server Version 5.2 FDP_ACF.1 controls rules governing user access to objects based on security attribute values and supports FDP_ACC.2. FDP_ACC.2 provides complete access control and enforces access controls on subjects and objects and all operations among the subjects and objects. FIA_SOS.1 reduces the likelihood of successful direct attack aimed at the identification and authentication functions, and thus supports FIA_UAU.1. FPT_STM.1 support time entries in audit records for FAU_GEN.1, as provided by the TOE environment. The FPT_STM.1 is not subject to any administration by any TOE administrator. FAU_GEN.1 provides the ability to track the security related events and actions. FAU_GEN.2 ensures that the individual responsible for generating an audit event is uniquely and unambiguously identified along with the audit data. FAU_SAR.1 and FAU_SAR.2 ensure that authorized users have the capability to review data from the audit records. 8.2.4 Non-IT security requirements rationale Table 7 below shows a mapping of the non-IT Security Requirements for the TOE environment to the Security Objectives for the environment. Table 7: Mapping of non-IT Security Requirements to Security Objectives for the Environment OE.MANAGE OE.OS-MANAGE OE.PHYSICAL OE.DATABASE OE.SOPHISTICATED OE.BACKUP OE.COMMUNICATION OE.TIME ER.ATTACK X X ER.BACKUP X X ER.COMMUNICATION X ER.OS-MANAGE X X ER.MANAGE X X ER.DATABASE X X The OE.TIME is addressed by the IT Security Requirement FPT_STM.1 for the TOE environment, as described in the security functional requirements rationale, section 8.2.1. 8.2.5 Appropriateness of assurance requirements The TOE is supposed to thwart attackers of limited resources. The EAL 3 assurance requirements bring enough assurance elements for the TOE, operating within its environment as described in this document. Furthermore, the EAL 3 assurance level is technically feasible and achievable based on the requirements on life cycle support, development documents, secure delivery procedure, and configuration management. It is appropriate to satisfy users’ expectations. Copyright IBM 2003 PAGE 44 IBM Tivoli Directory Server Version 5.2 8.3 TOE SummarySpecification Rationale The TOE summary specification rationale is intended to show that the TOE security functions and assurance measures are suitable to meet the TOE security (functional and assurance) requirements. To show that the selection of TOE security functions and assurance measures are suitable to meet TOE security requirements (functional and assurance), it is important to demonstrate the following: • The specified TOE IT security functions work together so as to satisfy the TOE security functional requirements. • That the started assurance measures are compliant with the assurance requirements. 8.3.1 TOE Security Functions rationale This section is intended to provide a demonstration that the TOE security functions satisfy all TOE SFRs included in the ST. This is accomplished by mapping the TOE security functions onto the TOE SFRs by Table 8, which shows that: • Each TOE SFR is mapped onto at least one TOE security function, and • Each TOE security function is mapped onto at least one TOE SFR. Note that FPT_STM.1 is a TOE environment security functional requirement and is to be satisfied by the TOE environment. Table 8: Mapping of Security Functions to Security Functional Requirements FAU_GEN.1 FAU_GEN.2 FAU_SAR.1 FAU_SAR.2 FDP_ACC.2 FDP_ACF.1 FIA_UAU.1 FIA_AFL.1 FIA_UID.1 FIA_ATD.1 FIA_SOS.1 FMT_MOF.1a FMT_MOF.1b FMT_MSA.1 FMT_MSA.3 FMT_MTD.1 FMT_SMF.1 FMT_SMR.1 FPT_RVM.1 F.AUDIT X X F.ACCESS_CONTROL X X F.I&A X X X X X X F.MANAGEMENT X X X X X X X X X F.REV_MEDIATION X Table 8 shows that all the TOE security functional requirements are addressed by the TOE security functions. Below is described how the IT security functions of the TOE are suitable to meet the TOE security functional requirements. FAU_GEN.1 The requirement for generation of audit events is satisfied by the security functions F.AUDIT, which will generate audit records for the specified events to an audit file. The audit record format and events are described as part of F.AUDIT. The audit record containing the timestamp is produced by F.AUDIT. (A reliable time-stamp is provided by the environment as expressed by the IT requirement for the TOE environment FPT_STM.1) FAU_GEN.2 The requirement is satisfied by the association of user identities (F.I&A) with audit events (F.AUDIT). FAU_SAR.1 The ability to read all audit records is provided by the security function Copyright IBM 2003 PAGE 45 IBM Tivoli Directory Server Version 5.2 F.MANAGEMENT, allowing the Directory Administrator and Members of the Administrative Group to view the audit file. FAU_SAR.2 The requirement is satisfied by the function F.MANAGEMENT, which is restricted only to Directory Administrators and Members of the Administrative Group, preventing any other users to read or erase the audit file. FDP_ACC.2 The requirement for complete access control is satisfied by the function F.ACCESS_CONTROL. All objects (directory entries and attributes) are subject to access control of F.ACCESS_CONTROL. FDP_ACF.1 The requirement is satisfied by the F.ACCESS_CONTROL, which enforces the directory access control SFP based on the entry owner information and the Access Control Information. FIA_AFL.1 The requirement for authentication failure is satisfied by F.I&A which will prevent any further authentication attempts of the same user after a specific number of consecutively failed authentication attempts. The number of failed attempts is three for a secure configuration, but the Directory Administrator and Members of the Administrative Group can specify any number. FIA_ATD.1 The requirement for user attributes is being fulfilled by F.I&A. The user attribute information is used and maintained by the F.I&A. FIA_SOS.1 The requirement for the verification of secrets is fulfilled by the user ID / password mechanisms being part of the security function F.I&A. The password policy constrains for a secure configuration are given. The Directory Administrator and Members of the Administrative Group has the ability to specify different values. FIA_UAU.1 The requirement is being met by F.I&A, which will only assign the user an identity (Distinguished Name) as part of a successful identification and authentication. Without a successful authentication the user will be regarded as unauthenticated and will only be given access to public information. FIA_UID.1 The requirement is being met by F.I&A. Since the identification and authentication is performed as one operation, see the description above of how FIA_UAU.1 is being met by F.I&A. FMT_MOF.1a The requirement is being fulfilled by F.MANAGEMENT, allowing the Directory Administrator and Members of the Administrative Group to modify the behaviour of the identification and authentication function, by specifying the password policy. FMT_MOF.1b The requirement is being fulfilled by F.MANAGEMENT, allowing the Directory Administrator to disable, enable and modify the behaviour of the audit function. FMT_MSA.1 The requirement is being fulfilled by F.MANAGEMENT, allowing the Directory Administrator to modify, delete and read the security attributes of the disable, enable and modify the behaviour of the audit function. FMT_MSA.3 The requirement for restrictive default values are being fulfilled by the security function F.MANAGEMENT by assigning restrictive values by installation and configuration made by the Directory Administrator and Members of the Administrative Group. FMT_MTD.1 The requirement for management of TSF data is being satisfied by the security function F.MANAGEMENT. Copyright IBM 2003 PAGE 46 IBM Tivoli Directory Server Version 5.2 FMT_SMF.1 The requirement for the TSF to provide management functions is being satisfied by the security function F.MANAGEMENT. FMT_SMR.1 The requirement for roles maintained by the TOE, the End User, Members of the Administrative Group and the Directory Administrator is satisfied by the security function F.MANAGEMENT. FPT_RVM.1 The requirement for non-bypassability of the TSP is satisfied by the security function F.REV_MEDIATION, ensuring that the access control functions are being invoked before access is given granted. The table above shows how the security functions work together to satisfy the security functional requirements. The requirements FAU_GEN.1, FAU_GEN.2, FAU_SAR.1, and FAU_SAR.2 define the requirements for the audit system by specifying the audit events, in relation to the other security functional requirements. The association of each audit event with user identities is consistent with the use of the identification and authentication function (FIA_UID.1 and FIA_UAU.1), so that FAU_GEN.2 has a basis for associating the events to user identities causing that event. In order to record the time and date of the events, FAU_GEN.1 requires a reliable time-stamp, which is provided by FPT_STM.1 (provided by the IT environment). The requirements FAU_SAR.1 provides the Directory Administrator and the Members of the Administrative Group with the capability to read all the audit information generated by the audit function. FAU_SAR.2 is preventing all other users from accessing the audit records. The requirements for access control is defined by the discretionary access control policy in FDP_ACC.2, providing complete access control based on the Entry Owner information and the Access Control Information and according to the evaluation order defined in FDP_ACF.1. The requirements for identification and authentication are addressed by FIA_AFL.1, FIA_ATD.1, FIA_SOS.1, FIA_UAU.1 and FIA_UID.1. The timing of identification and authentication is specified by FIA_UID.1 and FIA_UAU.1. Authentication failures are handled by FIA_AFL.1, by detecting and suspending users or prohibit further login after a certain number of failed consecutive login attempts. The attributes, including passwords, associated with individual users are specified in FIA_ATD.1. Restrictions on the passwords used for user authentication is specified by FIA_SOS.1, preventing the user to select weak or easy to guess passwords. The management functions are specified by FMT_SMF.1, specifying management functions for password management, password policy management, user management, access control management and audit management. The roles identified by the TOE is specified in FMT_SMR.1. The management of the authentication function is described in FMT_MOF.1a and the management of passwords, password policy, entry owner information and access control information and audit options is covered by FMT_MOF.1b. These management functions are also restricted to specific identified, authenticated and authorized users. For the discretionary access control, restricted attributes are specified by FMT_MSA.3. The management of TSF data is authorized users as specified in FMT_MTD.1. FPT_RVM.1 defines that the TSP enforcement functions are invoked and succeed before any other function is allowed to proceed, preventing bypassability of the TSP. The ability of the TOE security functions to fulfill the security functional requirements is demonstrated by the internal consistency of the security functional requirements, shown in section 8.2.3, and by the demonstration that each of these security requirements are being satisfied with one or more TOE security functions in combination as explained above. Copyright IBM 2003 PAGE 47 IBM Tivoli Directory Server Version 5.2 Copyright IBM 2003 PAGE 48 8.3.2 Minimum Strength of Function Level rationale The TOE mechanisms will resist technical attacks by unauthorized users. The TOE mechanisms will also resist user errors, system errors, or non-malicious actions by authorized users. Resistance to sophisticated types of attacks, when such resistance is required, is provided by the TOE operational environment. The environment also assumes that those individuals who have authorized physical access to the TOE are trusted to not behave maliciously. Consequently, a level of strength of function basic (SOF-basic) which indicates that a function provides adequate protection against straightforward or intentional breach of TOE security by attackers possessing a basic attack potential is consistent with the security objectives of the TOE. This claim applies to identification and authentication as specified in FIA_SOS.1, using the described settings, and satisfied by F.I&A. 8.4 Assurancemeasuresrationale This section is to show that the identified assurance measures are appropriate to meet the assurance requirements by providing mapping between the identified assurance measures and the assurance requirements, as shown in Table 9. In this case, the specification of assurance measures is done by reference to the appropriate document (e.g., Configuration Management Plan, System Architecture, User Guide, etc.). Rationale is provided to show that the referenced document (assurance measure) meets the requirements of the associated assurance requirement. Table 9: Mapping of Assurance Measures to Assurance Requirements ACM_CAP.3 ACM_SCP.1 ADO_DEL.1 ADO_IGS.1 ADV_FSP.1 ADV.HLD.2 ADV_RCR.1 AGD_ADM.1 AGD_USR.1 ALC_DVS.1 ATE_COV.2 ATE_DPT.1 ATE_FUN.1 ATE_IND.2 AVA_MSU.1 AVA_SOF.1 AVA_VLA.1 M.CAP X M.SCP X M.DEL X M.IGS X M.FSP X M.HLD X M.RCR X M.ADM X M.USR X M.DVS X M.COV X X M.FUN X M.IND X M.SOF X M.VLA X X X