IBM CONFIDENTIAL
Security Target
IBM Tivoli Directory Server Version 6.0
Fix Pack 1, Interim Fix 1
Version: 1.7.1
Status: Updated version
Last update: 2005-10-17
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 1
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 2
Document History
Version Date Changes Summary Author
0.1 2004-03-23 Initial version Initial version produced for IBM Staffan Persson
0.2 2004-03-30 Initial review comments/updates Mark McConaughy
0.3 2004-04-13 Updates based on the review Staffan Persson
0.4 2004-04-26 Remove proxy server and update
of TOE summary specification.
Staffan Persson
0.5 2004-06-02 Update after internal review and
review from Watson Lab
Staffan Persson
0.6 2004-07-05 Final draft Clarifications after internal review
to the descriptions of Proxy
Authorization Control and Group
Control.
Staffan Persson
1.0 2004-07-12 First version Update of description for Group
and Proxy Authorization Control.
Kristin M Hazlewood
and Staffan Persson
1.1 2004-11-08 Clarification of replication, ACLs
and of the audit functionality
Staffan Persson
1.2 2004-11-15 Updated due to evaluator findings Staffan Persson
1.3 2004-11-22 Updated with Master DN role Staffan Persson
1.4 2004-12-08 Addressed comments from QA,
fixed some typos
Staffan Persson
1.5 2005-02-14 Updated due to evaluator findings
mainly of SFR and passwd policy.
Kristin M Hazelwood
and Staffan Persson
1.6 2005-03-01 Minor corrections on the
password policy and access
control
Staffan Persson
1.7 2005-09-19 Updated description of replication,
use of Fix Pack 1 and removed
support for Digest
Kristin M Hazelwood
and Staffan Persson
1.7.1 2005-10-17 Updated reference name of TOE
with Interim Fix 1
Staffan Persson
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 3
Table of contents
1 Introduction..........................................................................................................................................7
1.1 ST Identification..............................................................................................................................7
1.2 ST Overview...................................................................................................................................7
1.3 IBM Tivoli Directory Server Overview ...........................................................................................7
1.4 CC Conformance Claim.................................................................................................................7
1.5 Strength of Function Claim............................................................................................................7
2 TOE Description..................................................................................................................................8
2.1 Product Type ..................................................................................................................................8
2.1.1 Defining a Directory............................................................................................................8
2.1.2 Directory clients and servers..............................................................................................9
2.1.3 Replication of directories....................................................................................................9
2.1.4 Distributed directory......................................................................................................... 12
2.1.5 Directory security............................................................................................................. 12
2.1.6 Directory Architecture and Operations........................................................................... 13
2.2 Security Roles and Services....................................................................................................... 13
2.2.1 Delivered Core Services ................................................................................................. 13
2.2.2 Security Roles.................................................................................................................. 14
Directory Administrator....................................................................................................... 14
Administrative Group Members......................................................................................... 14
Global Administrative Group Members............................................................................. 14
Master DN........................................................................................................................... 15
End User ............................................................................................................................. 15
2.2.3 Access Control................................................................................................................. 15
2.2.4 Auxiliary Services............................................................................................................. 16
2.3 TOE Boundary............................................................................................................................. 18
3 TOE Security Environment............................................................................................................. 20
3.1 Secure Usage Assumptions....................................................................................................... 20
3.2 Threats to security....................................................................................................................... 20
3.2.1 Threats addressed by TOE............................................................................................. 21
3.2.2 Threats addressed by the operating environment......................................................... 21
3.3 Organizational Security Policies................................................................................................. 21
4 Security Objectives.......................................................................................................................... 22
4.1 TOE Security Objectives............................................................................................................. 22
4.2 Environmental Security Objectives ............................................................................................ 22
5 IT Security Requirements ............................................................................................................... 24
5.1 TOE Security Functional Requirements .................................................................................... 24
5.1.1 FAU_GEN.1 Audit data generation................................................................................ 25
5.1.2 FAU_GEN.2 User identity association ........................................................................... 25
5.1.3 FAU_SAR.1 Audit review................................................................................................ 26
5.1.4 FAU_SAR.2 Restricted audit review .............................................................................. 26
5.1.5 FAU_STG.1 Protected audit trail storage....................................................................... 26
5.1.6 FDP_ACC.2 Complete access control........................................................................... 26
5.1.7 FDP_ACF.1 Security attribute based access control.................................................... 26
5.1.8 FIA_AFL.1a Authentication failure handling................................................................... 28
5.1.9 FIA_AFL.1b Authentication failure handling................................................................... 28
5.1.10 FIA_ATD.1 User attribute definition................................................................................ 28
5.1.11 FIA_SOS.1a Verification of secrets................................................................................ 29
5.1.12 FIA_SOS.1b Verification of secrets................................................................................ 29
5.1.13 FIA_UAU.1 Timing of authentication.............................................................................. 30
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 4
5.1.14 FIA_UID.1 Timing of identification .................................................................................. 30
5.1.15 FMT_MOF.1a Management of security functions behavior.......................................... 30
5.1.16 FMT_MOF.1b Management of security functions behavior.......................................... 30
5.1.17 FMT_MSA.1 Management of security attributes........................................................... 30
5.1.18 FMT_MSA.3 Static attribute initialization........................................................................ 31
5.1.19 FMT_MTD.1 Management of TSF data......................................................................... 31
5.1.20 FMT_SMF.1 Specification of Management Functions.................................................. 31
5.1.21 FMT_SMR.1 Security roles............................................................................................. 31
5.1.22 FPT_RVM.1 Non-bypassability of the TSP.................................................................... 32
5.2 TOE Environment Security Functional Requirements.............................................................. 32
5.2.1 IT Security Requirements for the underlying Operating System .................................. 32
FPT_STM.1 Reliable time stamps..................................................................................... 32
5.2.2 Non-IT Security Requirements for the TOE Environment............................................. 32
ER.ATTACK – Sophisticated Attacks................................................................................ 32
ER.BACKUP – Backup and Recovery.............................................................................. 32
ER.COMMUNICATION – Protection of the Communication........................................... 32
ER.OS-MANAGE – Management of the Operating System Environment..................... 32
ER.MANAGE – Management of the TOE......................................................................... 33
ER.DATABASE – Management of the Database ............................................................ 33
ER.ROUTE – Routing of LDAP Requests........................................................................ 33
5.3 TOE Security Assurance Requirements.................................................................................... 33
6 TOE Summary Specification.......................................................................................................... 34
6.1 TOE Security Functions.............................................................................................................. 34
6.1.1 F.AUDIT ........................................................................................................................... 34
Audit Generation (F.AUDIT)............................................................................................... 34
6.1.2 F.ACCESS_CONTROL.................................................................................................. 36
Order of Evaluation............................................................................................................. 38
Access Control Attributes................................................................................................... 38
Replication objects.............................................................................................................. 38
6.1.3 F.I&A................................................................................................................................. 39
User Authentication (F.I&A) ............................................................................................... 39
6.1.4 F.MANAGEMENT ........................................................................................................... 39
Roles (F.MANAGEMENT.1).............................................................................................. 39
Authentication Function (F.MANAGEMENT.2) ................................................................ 41
Authorization Functions (F.MANAGEMENT.3) ................................................................ 43
Audit Function (F.MANAGEMENT.4)................................................................................ 44
6.1.5 F.REF_MEDIATION........................................................................................................ 44
6.1.6 TOE Security Functions rationale................................................................................... 44
6.2 Assurance Measures.................................................................................................................. 45
7 Protection Profile Claims................................................................................................................ 48
7.1 PP Reference.............................................................................................................................. 48
8 Rationale............................................................................................................................................ 49
8.1 Security Objectives Rationale..................................................................................................... 49
8.2 Security Requirements Rationale............................................................................................... 51
8.2.1 Security Functional Requirements Rationale................................................................. 51
8.2.2 Dependency Analysis...................................................................................................... 54
8.2.3 Demonstration of Mutual Support Between Security Requirements............................ 55
8.2.4 Non-IT Security Requirements Rationale ...................................................................... 56
8.2.5 Appropriateness of Assurance Requirements............................................................... 57
8.3 TOE Summary Specification Rationale ..................................................................................... 57
8.3.1 TOE Security Functions Rationale ................................................................................. 57
8.3.2 Minimum Strength of Function Level rationale .............................................................. 61
8.4 Assurance measures rationale................................................................................................... 61
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 5
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 6
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
[RFC1274] The COSINE and Internet X.500 Schema, RFC 1274
[RFC1777] Lightweight Directory Access Protocol, RFC 1777
[RFC1778] String Representation of Standard Attribute Syntax's, RFC 1778
[RFC1779] String Representation of Distinguished Names, RFC 1779
[RFC1823] LDAP Application Program Interface (V2), RFC 1823
[RFC2052] A DNS RR for specifying the location of services (DNS SRV), RFC 2052
[RFC2219] Use of DNS Aliases for Network Services, RFC 2219
[RFC2222] Simple Authentication and Security Layer (SASL), RFC 2222
[RFC2247] Using Domains in LDAP/X.500 Distinguished Names, RFC 2247
[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
[RFC2596] Use of Language code in LDAP, RFC 2596
[RFC2696] LDAP Control Extension for Simple Paged Results Manipulation, RFC 2696
[RFC2829] Authentication Methods for LDAP, RFC 2829
[RFC2830] (V3) Extension for Transport Layer Security (TLS), RFC 2830
[RFC2849] The LDAP Data Interchange Format (LDIF) – Technical Specification, RFC 2849
[RFC2891] LDAP Control Extension for Server Side Sorting of Search Results, RFC 2891
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 7
1 Introduction
1.1 STIdentification
Title: Security Target for the IBM Tivoli Directory Server Version 6.0 Fix Pack 1, Interim Fix 1
Assurance level: EAL 4 augmented by ALC_FLR.1.
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 6.0 Fix
Pack 1, Interim Fix 1 (6.0.0.1-TIV-ITDS-IF0001). This Directory Server is running on Microsoft
Windows 2000, IBM AIX 5.2, Sun Solaris 9, 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 4 (EAL 4) augmented by ALC_FLR.1.
1.3 IBMTivoli DirectoryServer Overview
IBM Tivoli Directory Server version 6.0 (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 CC ConformanceClaim
The ST is Part 2 conformant and Part 3 conformant to the CC version 2.1, August 1999. 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 4 (EAL 4)
augmented with ALC_FLR.1, as specified in Part 3 of the CC, including the CCIMB final
interpretations as of February 2004.
1.5 Strength of FunctionClaim
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-medium. Thus, the global minimum strength level
claimed for the TOE is also SOF-medium.
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 8
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, which also covers the features that are not part of the
evaluated configuration. Feature that are not part of the evaluated configuration are explicitly
identified as such.
2.1 Product Type
The IBM Tivoli Directory Server Version 6.0 (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 all of them. The server, which is the core component of the
two, 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 interface to clients, used for the administration of the
LDAP server.
The ITDS Version 6.0 is a software product only, delivered over the Internet as a package
including five native packages that it provides for installation, these are:
1. LDAP Server and LDAP Server Administration Daemon Package
2. LDAP Proxy Server Package
3. LDAP Client Packages
4. Web Administration Package
5. Separate Language Packages for the LDAP Server, LDAP Server Administration
Daemon, and LDAP Proxy Server
Only the LDAP Server and LDAP Server Administration Daemon Package are part of the
TOE. The LDAP proxy server is not considered part of the TOE configuration. The other
packages, the LDAP client and administrator tools, the Web Administration Tool 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 web browser needed to administrate the TOE or the
Adobe Acrobat Reader to access the supplied online documentation. There is also a secure
configuration guide that must be downloaded and used for the installation and management
of the TOE.
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
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 9
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
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. The client server
configuration showing a single server is shown in the picture below.
Figure 1: Configuration showing a client and a single directory server
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 Replication of directories
In order to improve performance and availability, directories may be replicated. This means
that one master directory may be replicated to a number of copies allowing improved
availability to read accesses. Any changes made to the master affecting the replicas, will be
transmitted out to them. A user accessing a server may then either go to the master or to any
of the replicas.
Replication is enabled as replication agreements between a server and a client. A replication
agreement is part of the directory tree of the master. Changes replication is controlled by the
access control. In addition, this has been restricted in the evaluated configuration to the
Directory Administrator, Member of the Administrative Group and Master DN. Only these
roles are able to set up and change replication agreements.
For replication a number of differently configured directory servers may be involved. Any of
the following configurations may be used, acting in any of the following ways:
Client Server
LDAP
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 10
Master/peer The master/peer server contains the master directory information from
where updates are propagated to the replicas. All changes are made and
occur on the master server, and the master is responsible for propagating
these changes to the replicas. There can be several servers acting as
masters for directory information, with each master responsible for updating
other master servers and replica servers. This is referred to as peer
replication. Peer replication can improve performance and reliability.
Performance is improved by providing a local server to handle updates in a
widely distributed network. Reliability is improved by providing a backup
master server ready to take over immediately if the primary master fails.
1. Master servers replicate all client updates, but do not replicate updates
received from other masters.
2. Updates among peer servers can be immediate or scheduled.
3. Updates to the same entry made by multiple servers might cause update
conflicts that will be resolved based on update timestamps.
Forwarding A forwarding or cascading server is a replica server that replicates all
changes sent to it. This contrasts to a master/peer server in that a
master/peer server only replicates changes that are made by clients
connected to that server. A cascading server can relieve the replication
workload from the master servers in a network, which contains many widely
dispersed replicas.
Gateway Gateway replication uses gateway servers to distribute replication
information effectively across a wide area network. Gateways are servers
holding data, but also passing on the updates to other LDAP servers. The
primary benefit of Gateway replication is the reduction of network traffic
between geographically dispersed groups of LDAP servers.
Replica An additional server that contains a read-only copy of directory information.
The replicas are copies of the master (or the subtree that it is a replica of).
The replica provides a backup of the replicated subtree.
These are only different configurations of the directory server and not different types of
servers.
The evaluated configuration includes master, forwarding and replica servers, while the
gateway server is not part of the evaluated configuration.
In the evaluated configuration, there must not be more than one master for a given entry at
any particular point in time. Since gateway servers only serve a purpose in a configuration
including more than one concurrently updateable master server they are not meaningful in an
evaluated configuration. Conflict resolution is not included in the TOE. Since an entry can
only be updated on one server at any point in time, there should never be any replication
conflicts.
In addition, replication must be configured to be single-threaded and use synchronous
operations. Operating in this mode makes it easier to guarantee that update operations are
executed on the peer or replica in the same order they were on the supplier server.
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 11
In replication all the updates are made between the servers using LDAP operations.
Replication means that LDAP requests are made by servers, such as updates initiated by a
master server, or operations are passed on from cascading or gateway making these servers
act as LDAP clients for other servers.
Figure 2: Configuration showing a replication scenario with one master server.
The evaluated configuration using replication contains one master server and may contain
one or more forwarding servers with one or more replicas. If there is only one replica there is
no need for a forwarding server, as the forwarding server is only there to offload the master.
For redundancy, the master server may send all updates it receives to a peer. The peer is
equivalent to a master and may also act as a master in case the initial master no longer is
available. This has to be identified by the environment that has to act accordingly, by
connecting to the new master. During normal operation the master will send all updates it
receives to the peer. The environment must know only to contact the master and not the peer
for updates. The normal operation is shown in Figure 3 below. Showing the master server
sending all updates to the peer server.
Figure 3: Configuration showing a redundant peer server.
Client
Master
Server
LDAP
Replica
Replica
Replica
Forwarding
Server
LDAP LDAP
Client
Master
Server
LDAP
Replica
Replica
Forwarding
Server
LDAP LDAP
Peer
Server
LDAP
Replica
Replica
Forwarding
Server
LDAP
LDAP
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 12
In case the master server no longer is available, the environment must be able to detect this
and use the peer server as the new master. Once the original master server is up and
running again it will become the peer server with the new master peer will then provide it with
all the updates to make them synchronized. This is illustrated in Figure 4 below.
Figure 4: Peer takes over as new master server.
It is assumed that the environment is able to detect and switch over to a peer server and that
only requests are sent to the currently active master. Failing to do so will not lead to security
problems, but will not provide improvements to availability that the redundancy could bring.
The TOE environment must assure that any updates made in a replicated environment only
are made to the server currently active as master server. Failing to do so will lead to integrity
problems and may lead to security problems as updates may include changes to the security.
2.1.4 Distributed directory
The concept of a distributed directory is when a directory can be distributed over a number of
directory servers. Typically, different branches of a directory tree are handled by different
servers, but also a flat tree may be distributed over multiple servers. An LDAP request from
an LDAP client is coming in to an LDAP server, the server will then reply to the request either
with the result or with a referral to the servers that may be able to provide the result. This
means that the client will have to issue the request to the server referred to. How this is
performed is based on the entry affected by the request and referrals defining the partitioning
of the DIT. Distributed directory is not part of the evaluated configuration.
2.1.5 Directory security
A directory should support the basic capabilities needed to implement a security policy. First,
a method is provided to authenticate users. Authentication verifies that users are who they
say they are. A user ID and password is used for authentication, using simple bind. 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.
Client
New
Peer
LDAP
Replica
Replica
Forwarding
Server
LDAP LDAP
New
Master
LDAP
Replica
Replica
Forwarding
Server
LDAP
LDAP
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 13
2.1.6 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
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 attributes with values matching the compare
criteria in the specified entry,
• Abandon (terminate) a LDAP operation,
• Extended operations, which are server side enhancements to the LDAP operations
as delivered by IBM.
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 14
In addition, the server may allow unauthenticated users to perform any operation on any
entries or attributes that are not blocked by any ACL. There are a range of extended
operation available as part of the core service. One extended operation, event notification, is
not supported by the evaluated configuration and must therefore be deactivated by the
Directory Administrator in the configuration.
2.2.2 Security Roles
The ITDS supports five different security roles: Directory Administrator, Member of the
Administrative Group, Member of the Global Administrative Group, Master DN, and End
User. A user account for the TOE operates as one, and only one of these roles. Only by
having different accounts a user may act in different roles, except for the case where
administrators can use the Proxy Authorization feature to act as an end user. The following
sections describe the capability of each one.
Note: The ITDS has additional roles, which are 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.
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.
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 each End User
will have over entries.
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 and maintain accountability of
their actions. These users can perform most administrative tasks. Excepted are operations
affecting the accountability or operations that may increase the privileges of those users,
such as delete audit files or to change the password of the Directory Administrator. These
Administrative Group Members may also be called local administrative group members, in
contrast to the Global Administrative Group Members, which are described below.
Global Administrative Group Members
Global administrative group members are users that have been assigned the same set of
privileges as the administrative group when it comes to access to entries in the database
backend. However, they have no special privileges or access rights to any other data or
operations that are not related to the database backend, such as the configuration file or
audit data. All global administrative group members have the same set of privileges. The
global administrative group is a way for the directory administrator to delegate rights in a
distributed environment. The Directory Administrator and the Administrative Group Members
may act as global administrative group members using the proxy authorization.
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 15
Master DN
The master server DN is a role use by replication that can update the entries under a
replica’s or a forwarding replica’s replication context to which the DN is defined as a master
server DN. The master server DN can create a replication context entry on a replica or
forwarding replica if the DN is defined as the master server DN to that specific replication
context or as a general master server DN.
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 is authenticated during the bind operation. Once the End User
is authenticated, they may access any of the attributes of any entry to which they have
permissions.
2.2.3 Access Control
Access control to LDAP entries is enforced by the directory server back ends in which the
entries are maintained. There are two different ways in which access control is implemented,
hard coded as with the configuration backend and configurable as with the data base back
end. The hard coded access rights are very restricted and cannot be changed by anyone, not
even the administrator or at installation, while access to LDAP entries stored in the database
backend are subject to configuration as described below.
Access is controlled to the LDAP attributes under the control of the TOE. Attributes requiring
similar permissions for access are grouped together in five types of access classes. These
classes are discrete; access to one class does not imply access to another class.
These classes are defined as part of the schema. The schema can only be changed by the
Directory Administrator, Members of the Administrative group, and the master server role, in
the case of replication.
Permissions are set with regard to the attribute access class as a whole. The permissions set
on a particular attribute class apply to all attributes within that access class unless individual
attribute access permissions are specified. The following for access classes exists:
• System attributes can only be changed by the directory server itself and not be
changed by any user, except through the Administrative Control. They can only be
modified by the Directory Administrator using the administrative control privilege with
the modify operation. Examples of such attributes are time stamps.
• Restricted attributes can only be changed by the attribute owner and not by anyone
else. By default all users have read access to the restricted attributes but only the
entry owner can create, modify, and delete these attributes. Examples of such
attributes are the ACLs controlling access to attributes.
• Critical, sensitive and normal are the classifications used for user created attributes.
The default class for attributes created by a user is normal. The access class of an
attribute may be changed by the user to sensitive or critical to assign specific (more
limited) access. While normal may be used for any information, sensitive may for
example be used for private information and or critical for even more sensitive
information.
In addition, it is possible to specify access rules for individual entries or parts of the directory
tree using access control lists.
In addition to the access control given to users based on the subjects DN, users may also be
given proxied authorization by becoming a member of a proxied authorization group. The
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 16
members of the proxied authorization group can assume any identities except the Directory
Administrator or Members of the Administrative Group. These administrators will be granted
proxied authorization right by default, without explicitly being a member of a proxied
authorization group.
There are two kinds of ACLs, non-filtered based ACLs and filtered based ACLs.
• Non-filter based ACLs apply explicitly to the directory object that contains them and
may be propagated to none, some, or all its descendant objects as configured. If
propagated, the ACL is propagated to all descendant objects that do not contain
explicit ACLs. If a descendant object contains an explicit propagating ACL, then that
propagation supersedes the one initiated by the ancestor object. If a descendant
object contains an explicit non-propagating ACL, then that object is skipped over,
and the ancestor's propagation process continues for the rest of the descendant
objects.
Because of this propagation behavior, it is inconvenient to achieve fine ACL
granularity, without having to specify explicit ACLs for many of the objects in a sub-
tree. The finer the ACL granularity desired, the more cumbersome the process
becomes.
• Filter based ACLs may apply to the containing object, and some, or all of the objects
in the descendant tree. The Access Control Information is applied to an object based
on a match with the comparison filter. Filtered ACLs accumulate upward along the
ancestor chain in a sub-tree. Accumulation means that matching filter ACLs defined
in the ancestor chain are collectively applied to the target object. Filter based ACLs
have the advantage of convenience when finer ACL granularity is needed, and they
provide for hierarchical refinement of access permissions through accumulation.
Filtered ACL's provide the option of defining all ACL's at the base of the directory
tree, and using the filters to select the entries that various ACL's should be applied
to. Conversely, if you wish to apply different access rules to different entries within
the tree when using non-filtered ACL's, then they must be dispersed within the tree.
2.2.4 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 data backup and restore capability. It
interoperates with the IETF LDAP V3 and V2 based clients. Besides supporting the standard
LDAP operations, it additionally includes a number of features listed below. These features
are all included in the evaluated configuration unless explicitly stated.
• 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
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 17
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
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. SASL mechanisms are not part of the TOE and
may not be used in the evaluated configuration. Only simple bind (user ID and
password) authentication is allowed. The passwords selected by End Users, the
Members of the Administrative Group, Global administrative group members, Master
DN and the Directory Administrator are subject to a password policy. The password
policy for the End User and Global Administrative Group Members is determined by
the Global Administrative Group Members, Master DN, Members of the
Administrative Group or the Directory Administrator. The password policy of the
Master DN, Administrative Group Members and Directory Administrator can only be
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.
• 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. Although distributed directory is not part of the evaluated configuration
the feature of referral is available and is used for replication purposes.
• 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 logged in a separate database in
the LDAP server to support meta-directories or client queries to monitor directory
updates.
• 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
Directory 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.
• Proxy Authorization Control – An LDAP control is provided to allow administrators or
trusted users (as specified in the Proxy Authorization Group), to perform individual
LDAP operations on behalf of other end users. When this control is included, all
access control decisions made for the operation are based on the user id specified in
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 18
the control. End users and global admin group members may not use this control to
assume an administrative role. Directory Administrators and Members of the
Administrative Group may use this control to assume an End User, or Global
Administrator role.
• Group Authorization Control – An LDAP control is provided to allow administrators or
trusted users (as specified in the Proxy Authorization Group), to perform individual
LDAP operations as a member of the set of asserted groups. When this control is
included, all access control decisions made for the operation are based on the groups
specified in the control.
2.3 TOEBoundary
The TOE can be illustrated as in Figure 3, showing the basic client/server based ITDS
architecture. The rectangle represented by the dashed lines indicates the TOE boundary, i.e.
the standalone directory sever with 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 underlying hardware and operating system, the database, the LDAP client and the
TLS/SSL module are part of the TOE environment. The TOE and the DB2 database will run
on the same machine. In case of replication, when different instances of the TOE run on
different machines, they will all have their own DB2 databases running on their respective
machine.
Figure 5: IBM Tivoli Directory Architecture and TOE Boundary
The TOE consists of two components: the directory server component and the administration
daemon. User clients may connect either to the LDAP server (shown in the picture above as
the Directory Server) or to the administration daemon, using the LDAP protocol but using
Directory Server
Database
Operating System and
Hardware
LDAP Client
Administration
Daemon
TLS/SSL
TOE Boundary
Single Server
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 19
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. The picture below shows the
simplest configuration of the ITDS as a single server.
The hardware and the operating system the ITDS uses are part of the TOE environment. The
TOE assumes a secured communication link between itself and the client.
It is possible to install multiple server instances of ITDS, but in the case of Microsoft Windows
2000 the evaluated configuration is restricted to one server instance of the ITDS on each
single machine.
When using replication, both master/peer server, forwarding and replicas may be included
which means that more than a single server will be used. Each server will have its own
administration daemon, directory server and database, as in the single server configuration.
However, the different servers will interact with each other and not just with an LDAP client.
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 20
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.ADMIN The TOE Administrators (i.e. the Directory Administrator, the Members of
the Administrative Group and the Members of the Global Administrative
Group) are trustworthy to perform discretionary actions in accordance with
security policies and not to interfere with the abstract machine, making
sure that the TOE is competently administered.
A.TOEENV The TOE Environment Administrators are trustworthy to perform
discretionary actions in accordance with security policies, assuring that the
TOE environment is competently installed and administered.
A.COMM It is assumed 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 possess the necessary authorization to access at
least some of the information managed by the TOE and are expected to
act in a cooperating manner in a benign environment.
A.ROUTE It is assumed that in a replicated environment, all the update requests are
made to the master server only. It is also assumed that all replicas are
under the same administration and the protection in the TOE environment
is as for the TOE (master server).
A.TIME It is assumed that a reliable time function is provided by the TOE
environment to support the generation of audit records.
3.2 Threatstosecurity
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 threat agents are assumed to originate from a well-managed user community in a non-
hostile working environment, and hence the product protects against threats of security
vulnerabilities that might be exploited in the intended environment for the TOE with medium
level of expertise and effort. The TOE in accordance with the strength of function claimed
protects against straightforward or intentional breach of TOE security by attackers
possessing a medium attack potential.
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 21
3.2.1 Threats addressed by TOE
The TOE addresses the threats discussed below.
T.ENTRY A 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 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:
• authenticated uniquely by the ITDS, or
• unauthenticated, and appears as an anonymous user.
T.ACCOUNT Security relevant actions occur without awareness by Directory
Administrator. 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.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 given access
to the TOE.
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 22
4 Security Objectives
This section defines the security objectives for the TOE and its environment respectively.
4.1 TOESecurityObjectives
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, Members of the
Administrative Group, and Members of the Global 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 be adequately satisfied 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.ENVMANAGE Those responsible for the TOE environment must ensure that the underlying
operating system and hardware is configured and managed in a secure way.
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 and replicas are protected from unauthorized modification and
disclosure of communication data.
OE.ROUTE The TOE environment must ensure that in a replicated environment all the
update requests are made to the master server only. It must also ensure that
that all replicas are under the same administration and has the same
protection as is required for the TOE (master server).
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 23
OE.TIME The TOE environment must provide a reliable time source.
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 24
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) 4
assurance components from Part 3 of the CC, augmented with ALC_FLR.1 for flaw
remediation.
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 been performed for FIA_AFL.1,
FIA_SOS.1 and FMT_MOF.1. The two SFR components are identified by adding the letter a
and b after the SFR as for 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
FAU_STG.1 Protected audit trail storage
FDP_ACC.2 Complete access control
FDP_ACF.1 Security attribute based access control
FIA_AFL.1a Authentication failure handling (for the end users)
FIA_AFL.1b Authentication failure handling (for the administrators)
FIA_ATD.1 User attribute definition
FIA_SOS.1a Verification of secrets (for the end users)
FIA_SOS.1b Verification of secrets (for the administrators)
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
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 25
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)
• 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
• Compare (LDAP v2 and v3)
• Event notification (LDAP v3)
• Extended operations (LDAP v3)
Application Note: All supported LDAP operations performed on the server or administration
daemon are audited. The list above shows the full set of LDAP operations supported by the
server. However, the administration daemon only supports a limited set of LDAP operations,
i.e.: bind, unbind, search, and extended operations. All other LDAP operations will be
rejected by the administration daemon and will therefore not be audited by the administration
daemon. Note that the operation event notification, although listed above is not considered
part of the evaluated configuration
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 identity. 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 identity.
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 26
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-access.
Application Note: Only the Directory Administrator and the Administrative Group Members
only have read access.
5.1.5 FAU_STG.1 Protected audit trail storage
FAU_STG.1.1 The TSF shall protect the stored audit records from unauthorized
deletion.
FAU_STG.1.2 The TSF shall be able to prevent unauthorized modifications to the audit
records.
Application Note: Only the Directory Administrator has the privilege to delete audit records.
This is done by deleting the whole content of an audit file.
5.1.6 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.
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. Users using the group control assume group membership in the asserted set of
groups and the ACL restrictions for the asserted groups.
5.1.7 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.
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 27
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, the Administrative Group Members and
the Global Administrative Group Members are the entryOwners for all objects in the
directory by default, and this entryOwnership can 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 with one exception. The
Directory Administrator and Members of the Administrative Group can become Global
Administrators by using the proxied authorization. Entries under the “cn=Configuration”
suffix are not subject to configurable access control. These server configuration settings
may only be read or updated by the Directory Administrator and the Administrative
group members. Global Administrative Group Members and end users have no access
to the server’s configuration. In the evaluated configuration, access to replication related
objects are restricted to the rights related to the Directory Administrator, the
Administrative Group Members and to the Master DN only.
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.
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 28
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.8 FIA_AFL.1a 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
Administrator has reset that End User’s password.
Application Note: The number of unsuccessful authentication attempts can be specified by
the Directory Administrator, a Member of the Administrative Group, a Member of the Global
Administrative Group, or Master DN as referred to by the term Administrator above. The
value of three unsuccessful attempts is the one selected for the evaluated configuration. The
authentication failure handling applies to all End Users and Members of the Global
Administrative Group, but not to the Directory Administrator, to the Members of the
Administrative Group, or to the Master DN. For these administrative users the FIA_AFL.1b
applies.
5.1.9 FIA_AFL.1b Authentication failure handling
FIA_AFL.1.1 The TSF shall detect when 3 unsuccessful authentication attempts occur
related to authentication attempts of the Administrator.
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 Administrator
from any host other than the one on which the directory server is running. After a
successful local login, or a restart of the directory server, the Administrator’s
account is restored to normal access.
Application Note: This authentication failure handling only applies for the Directory
Administrator or Administrative Group members, as referred to by the term Administrator
above. 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 evaluated configuration.
Local login is only possible for the Directory Administrator. In case of a blocked account, the
Administrative Group Members and Master Server DN cannot log on until the Directory
Administrator changes their password.
5.1.10 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
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 29
• 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. All of these attributes except pwdChangedTime and pwdReset are maintained for the
Directory Administrator, for the Administrative Group members, and for the Master DN.
5.1.11 FIA_SOS.1a 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, Members of the Administrative Group,
Members of the Global Administrative Group and Master DN 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-medium. This claim is based on the setting above for the verification of secrets, when
using simple bind. The Directory Administrator, Administrative Group Members, or Master
DN’s passwords are not subject to these constraints. They are subject to the constraints in
FIA_SOS.1b described below.
5.1.12 FIA_SOS.1b 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 of 2 non-alphabetic character
• Minimum of 4 alphabetic characters
• Maximum of 2 identical characters
Application Note: The Directory Administrator, Members of the Administrative Group, and
Master DN are subject to these constraints, when using the simple bind. The above listed
values are those that are considered for a secure configuration. The claimed SOF for the
authentication mechanism is SOF-medium. This claim is based on the setting above for the
verification of secrets, when using simple bind.
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 30
5.1.13 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 operations on public information, without a
previous authentication if anonymous bind is allowed and the ACLs are allowing this. The
bind/unbind is part of the user authentication and abandon is an allowed operation also for
unauthenticated users.
5.1.14 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.15 FMT_MOF.1a Management of security functions behavior
FMT_MOF.1.1 The TSF shall restrict the ability to modify the behavior of the functions
authentication mechanism to the Directory Administrator and the Members of the
Administrative Group.
5.1.16 FMT_MOF.1b Management of security functions behavior
FMT_MOF.1.1 The TSF shall restrict the ability to disable, enable, and modify the
behavior of the functions audit service to the Directory Administrator.
5.1.17 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 Global Administrative
Group, 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, Members of the Administrative Group or Members of the
Global Administrative Group
c) Entry Owner Information – End User (entry owner), Directory
Administrator, Members of the Administrative Group or Members of the
Global Administrative Group
d) Access Control Information – End User (entry owner), Directory
Administrator, Members of Administrative Group or Members of the Global
Administrative Group
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 31
e) Audit options – Can be read by Members of the Administrative Group or
Directory Administrator, but only modified by the Directory Administrator
f) Replication behavior – Changes to the replication behavior can only be
made by the Directory Administrator, the Administrative Group Members
and the Master DN
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.18 FMT_MSA.3 Static attribute initialization
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, Members of the Global Administrative Group, Master DN 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.
Application Note: Restrictive attributes apply to the privileges and rights granted to new
users and to new attributes created. This is interpreted so that new users will not be assigned
any special privileges. However, by default all users have read access rights to normal,
system, and restricted attributes.
5.1.19 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 or Members of the Administrative Group.
5.1.20 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
f) Replication management.
5.1.21 FMT_SMR.1 Security roles
FMT_SMR.1.1 The TSF shall maintain the roles Directory Administrator, Member of
the Administrative Group, Member of the Global Administrative Group, Master DN
and End User.
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 32
5.1.22 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.
5.2.1 IT Security Requirements for the underlying Operating System
FPT_STM.1 Reliable time stamps
FPT_STM.1.1 The TSF shall be able to provide reliable time stamps for its own use.
5.2.2 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
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.
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 33
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.
ER.ROUTE – Routing of LDAP Requests
In an environment using replication, all LDAP requests must be routed to the currently active
master server. This is to avoid the possibility of a replication conflict occurring because the
same entry was updated on two peer servers at about the same time, leading to potential
inconsistencies. The environment must ensure that that all replicas are under the same
administration and has the same protection as the TOE (master server). This applies both to
the physical, logical and administrative protection of the server as to the communication with
the replication servers.
5.3 TOESecurityAssuranceRequirements
The target evaluation assurance level is EAL 4 [CC] augmented by ALC_FLR.1.
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 34
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 TOESecurityFunctions
The TOE security functions are described as follows:
6.1.1 F.AUDIT
The TOE provides audit generation service; the administration daemon and the server each
have an audit 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 log files are stored as text files, which are managed and reviewed using the audit
review as part of F.MANAGEMENT.4.
Audit Generation (F.AUDIT)
The audit service will generate at least one audit log entry for each valid LDAP request
received by the server, when configured to do so. The entry is generated when the
administration daemon and 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 three versions of the audit function that can be selected by the Directory
Administrator, version 1, 2 or 3. Only version 3 must be used in an evaluated configuration,
since only version 3 is able to audit the operations as required.
In addition to the LDAP operations, 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
administration daemon or 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 corresponding 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 audit version 3 message entry generated by the administration daemon,
and the server will be:
AuditV3 -- 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:
AuditV3 -- Timestamp1 -- Version number + [TLS] [SSL] +
[unauthenticated or anonymous] Operation—bindDN: server
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 35
encoded DN string -- client:Client IP address:Port number --
ConnectionID: xxxx -- received: Timestamp2 -- Result or
Status string
[Unique ID]
[Control String]
Where:
Timestamp 1
Is the local time the entry is logged (i.e., when the processing of the request is done).
Version number +[TLS] [SSL]+[unauthenticated or anonymous] Operation
Shows the LDAP request that was received and processed. Version number is V3, in
the evaluated configuration. TLS or SSL indicates whether TLS or SSL was used.
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 string
Shows the result or status of the LDAP operation. The result is a text message like
“success” or “operationsError”.
Unique ID
This identifier is sent from the client to the server in its own control, it is for example
used for proxied authorization, i.e. when a user is performing an operation on behalf
of another user id. In such an environment the unique ID is passed along with the
operation to any other servers that are chained to. The other servers also include the
ID in their audit logs as part of auditing the control that carried the ID, to allow the
operations to be correlated in audit logs from multiple servers.
Control String
This section contains an OID and appropriate content related to any control that was
included with the operation being logged.
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
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 36
bind); authenticationMechanism – the authentication mechanisms used, but only in
case a SASL mechanisms is being used.
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
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.
Compare
entry – the DN of the entry involved in the compare; attribute – the name of the
attribute type whose value is being compared.
Delete
entry - the DN of the entry requested to be 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. Note that this operation is
not supported as part of the evaluated configuration.
Event notification extended operation: unregister
eventID – the event notification ID created by the server during registration. Note that
this operation is not supported as part of the evaluated configuration.
Extended operation (with exception of event notification)
OID – the OID value for the extended operation1
.
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
1
Some extended operations include parameters in addition to the OID that are logged here.
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 37
(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 authorization by becoming a member of a proxied authorization group. The
members in the proxied authorization group can assume any authenticated identity except
the Directory Administrator or Members of Administrative Group or Global Administrative
Group. The proxied authorization control for specifying an authorization identity is on a per
LDAP operation basis instead of a 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 each LDAP request, stating the proxied DN which will be the subject DN under which the
operation will be performed.
The members of the proxied authorization group can assume any identities except the
administrator or administrative group members. The administrator, administrative group
members, or global administrative group members will be granted proxied authorization right
by default, without explicitly being a member of a proxied authorization group. The Directory
Administrator and members of the administrative group are able to proxy to global
administrative group members.
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
Control Information). When determining access, the entryOwner information and the ACI
information are 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.
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 38
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.
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.
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.
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
Replication objects
Replication objects are controlling replication agreements and are subject to access control
as other objects. In the evaluated configuration access to replication objects is restricted to
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 39
the Directory Administrator, the Administrative Group Members and to the Master DN. No
other roles will be able to modify/add/delete/modrdn to any replication related objects.
6.1.3 F.I&A
User Authentication (F.I&A)
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. There is only one
possible authentication method available for the evaluated configuration. The TOE can only
use a simple user ID / password authentication method to authenticate users as defined in
RFC 2251. Users are maintained in the directory.
The authentication mechanism is selected by the administrator and the behavior of the
authentication mechanism is, in the case of simple bind, controlled by the password policy
specified by the Directory Administrator (see F.MANAGEMENT.2 below).
The administrator can also specify, for simple bind, 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
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)
Roles (F.MANAGEMENT.1)
The TOE supports five security roles: Directory Administrator, Administrative Group Member,
Global Administrative Group Member, Master DN and End User.
All five roles are defined within the TOE. While the ordinary End Users and the Master DN
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.
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 40
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 Directory Administrator or Members of the Administrative Group also have the ability to
define Members of the Global Administrative Group, which will have administrative access to
all entries in the directory except the configuration file entries (all entries under
cn=configuration).
The Members of the Administrative Group or Global Administrative Group also cannot
perform some extended operations (see table below).
Table 2: Extended Operations and Roles
Extended operation, Short name, description and OID
Directory
Administrator
Administrative
Group
Member
Global
Administrative
Group
Member
Master
DN
End
User
Start TLS - Request to start Transport Layer Security. OID = 1.3.6.1.4.1.1466.20037 Yes Yes Yes Yes Yes
Event Registration - Request Request registration for events in SecureWay V3.2
Event support. OID = 1.3.18.0.2.12.1
Yes Yes 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 Yes Yes
Begin Transaction - Begin a Transactional context for SecureWay V3.2 OID =
1.3.18.0.2.12.5
Yes Yes 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 Yes Yes
Enable and Disable Tracing Dynamically. OID = 1.3.18.0.2.32.14 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
replication topology. OID = 1.3.18.0.2.12.15
Yes Yes Yes Note 3 Note 4
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 Yes Note 3 Note 4
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 Yes Note 3 Note 4
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 Yes Note 3 Note 4
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 -- -- --
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 41
Extended operation, Short name, description and OID
Directory
Administrator
Administrative
Group
Member
Global
Administrative
Group
Member
Master
DN
End
User
Update Configuration Request - Request to update server configuration for IBM
Directory Server. OID = 1.3.18.0.2.12.28
Yes 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 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 Note 2 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 Yes Yes
Control Server Tracing - Activate or deactivate tracing in the IBM Directory Server.
OID = 1.3.18.0.2.12.40
Yes Yes Yes Yes --
Group Evaluation – This operation is used in a distributed directory environment to
determine all groups that a particular DN is a member of. OID = 1.3.18.0.2.12.50.
Yes Yes Yes Yes --
Topology Replication – This operation is used to replicate the objects that define the
topology of a particular replication context, such as the replication agreements for that
context. Any user with update rights to the Replication Group Entry of the context is
allowed to issue this extended operation. OID = OID 1.3.18.0.2.12.54.
Yes Yes Yes Yes Note 4
Event Update – Request to reinitialize the event notification configuration OID =
1.3.18.0.2.12.31 (this operation can only be initiated by the server, not any user)
No No No No No
Log Access Update – Request to reinitialize the log access plugin configuration OID=
1.3.18.0.2.12.32 (this operation can only be initiated by the server, not any user)
No No No No No
Unique Attributes – Request to get the duplicate values for an attribute. OID=
1.2.18.0.2.12.44
Yes Yes Yes Yes No
Account Status – This operation is used to determine if an account is locked by
password policy. OID = 1.3.18.0.2.12.58
Yes Yes Yes No No
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.
Note 2: Any connection can be killed, except connection associated with the Directory
Administrator and Members of the Administrative Group.
Note 3: Any DN defined as either the Master DN for that particular replication context or as
the general Master DN can issue these extended operations (for that particular replication
context).
Note 4: Any user who has “write” access granted in the ACL’s on the Replication Group
Object can issue any of these extended operations for that particular replication context.
Authentication Function (F.MANAGEMENT.2)
End User Authentication Management
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
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 42
• Minimum number of non-alphabetic characters
• Maximum number of repeated characters
• Maximum lifetime of a password
• Minimum lifetime of a password
The Directory Administrator or Members of the Administrative Group 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 an
End 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)
• Minimum 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
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 43
Administrative User Authentication Management
The Directory Administrator can configure the behavior of the authentication function for the
administrative users by setting the following values, common to all administrators:
• Minimum length of passwords – default for secure configuration is 8
• 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 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: Administrator cannot log in from a remote host until the server is
restarted or the administrator successfully logs in on the local host (pwdLockout –
TRUE and pwdLockoutDuration – 0)
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 Administrative 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 neither bye the End User nor by the Directory Administrator nor the Members of
the Administrative Group. An example for these attributes is 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.
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 44
Access to entries under the “cn=configuration” suffix are subject to a hard coded access
control and not configurable access control by any user or administrator.
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),
compare, groups on the group control, attributes on the group evaluation operation,
the event notification extended operation: registration and unregistration, and all
other extended operations.
• 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. Also note
that the event notification is not part of the evaluated configuration.
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
While also the Administrative Group Members can inquiry the number of lines and view audit
records, only the Directory Administrator can 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.
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 45
6.2 AssuranceMeasures
The assurance requirements 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 and in the
flaw remediation
d) Confirmation that the guidance documentation is adequate
e) Confirmation that the development documentation is correct and complete
f) Verification of a sample of the vendor functional testing
g) Verification of the developers analysis for vulnerabilities and resistance against
obvious penetration attacks
h) Independent functional testing
To define the assurance measures claimed to satisfy the security assurance requirements
specified in section 5.3, 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 description of the
relevant processes and appropriate documentation associated with each requirement.
Table 3: Assurance Measures
CC Assurance Component Assurance Measure
ACM_AUT.1 M.AUT
Configuration Management Version Control (CMVC) is the tool used to manage
configuration items of the TOE. The configuration management procedures and
tools are identical to the ones used for previous versions of ITDS that have been
evaluated under the CC scheme. The procedures are described in separate
documents.
ACM_CAP.4 M.CAP
Configuration Management Version Control (CMVC) is used to manage
configuration items of the TOE. Lotus team rooms are only used for distribution
of documentation and for non-TOE documents that are not subject to changes,
such as protocols from meetings.
ACM_SCP.2 M.SCP
In addition to the previous evaluation, all documentation will be under the control
of the CMVC too or in a Notes Teamroom Database, including the test results.
ADO_DEL.2 M.DEL
The software along with all documentation 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 M.IGS
This process will be described in the document: IBM Tivoli Directory Server
Version 6.0 Installation and Configuration Guide and in the IBM Tivoli Directory
Server and in the Security Guide.
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 46
CC Assurance Component Assurance Measure
ADV_FSP.2 M.FSP
The functional specification will be provided in the document IBM Tivoli
Directory Server Version 6.0 Functional Specification.
ADV_HLD.2 M.HLD
The high level design will be described in the documents IBM Tivoli Directory
Server Version 6.0 High Level Design.
ADV_IMP.1 M.IMP
The full source code of the TOE is provided for the evaluation.
ADV_LLD.1 M.LLD
The low-level design documentation is provided for all subsystems that
implement TSF. These are new design documents developed for this release
describing new components of ITDS 6.0 making up the TOE.
ADV_RCR.1 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.
ADV_SPM.1 M.SPM
A separate document describing the Security Policy Model is provided to the
evaluation facility.
AGD_ADM.1 M.ADM
The administrator guidance will be provided with the IBM Tivoli Directory Server
Version 6.0 Administration Guide
AGD_USR.1 M.USR
The user guidance will be provided with the IBM Tivoli Directory Server Version
6.0: C-Client SDK Programming Reference
ALC_DVS.1 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.
ALC_FLR.1 M.FLR
Flaw remediation measures are implemented by offering well-defined points of
contact to its customers for reporting potential security flaws. Defects and their
status are tracked within the support chain as well as in the CM system for the
implementation representation. A dedicated website notifies customers of
updates to the TOE that implement corrections due to identified flaws.
ALC_LCD.1 M.LCD
The life cycle security maintained by corporate security procedures along with
specific Tivoli Software Group procedures addressing the software development
process and description of the tools and how they are used for development.
ALC_TAT.1 M.TAT
See above.
ATE_COV.2 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
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 47
CC Assurance Component Assurance Measure
ATE_DPT.1 See above
ATE_FUN.1 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 M.IND
Independent testing will be performed by the evaluation facility
AVA_MSU.2 M.VLA
The misuse analysis will be provided as an update to the vulnerability analysis
made for the EAL 4 evaluation.
AVA_SOF.1 M.SOF
A Strength of Functional analysis will be provided for the password mechanism,
based on the Strength of Function Analysis made for the previous evaluation.
AVA_VLA.2 M.VLA
A vulnerability analysis will be provided that describes IBM’s approach to identify
vulnerabilities of ITDS 6.0 as well as the results of the findings.
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 48
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.
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 49
8 Rationale
8.1 SecurityObjectivesRationale
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.CRASH
TE.PASS
A.PHYSICAL
A.ADMIN
A.TOEENV
A.COMM
A.COOP
A.ROUTE
A.TIME
P.PUBLIC
O.AUTHENTICATE X X
O.AUTHORIZE X X
O.ACCOUNT X
O.BYPASS X
OE.MANAGE X X X
OE.ENVMANAGE X X X
OE.PHYSICAL X X
OE.DATABASE X X X X
OE.SOPHISTICATED X
OE.BACKUP X
OE.COMMUNICATION X X
OE.ROUTE 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
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 50
and OE.COMMUNICATION.
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.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.ENVMANAGE 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.ADMIN OE.MANAGE, OE.ENVMANAGE 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.
A.TOEENV OE.MANAGE, OE.ENVMANAGE 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
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 51
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.ROUTE OE.ROUTE requires that all the updates in a replicated environment
are made to the current master server and not to any other server. It
is also assumed that all replicas are under the same administration
and that the same protection as required by the TOE (master
server).
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 SecurityRequirementsRationale
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.ENVMANAGE
OE.PHYSICAL
OE.DATABASE
OE.SOPHISTICATED
OE.BACKUP
OE.COMMUNICATION
OE.ROUTE
OE.TIME
FAU_GEN.1 X
FAU_GEN.2 X
FAU_SAR.1 X
FAU_SAR.2 X
FAU_STG.1 X
FDP_ACC.2 X
FDP_ACF.1 X
FIA_AFL.1a X
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 52
O.AUTHENTICATE
O.AUTHORIZE
O.ACCOUNT
O.BYPASS
OE.MANAGE
OE.ENVMANAGE
OE.PHYSICAL
OE.DATABASE
OE.SOPHISTICATED
OE.BACKUP
OE.COMMUNICATION
OE.ROUTE
OE.TIME
FIA_AFL.1b X
FIA_ATD.1 X
FIA_SOS.1a X
FIA_SOS.1b 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.1a for end users and FIA_AFL.1b for the administrators
ensures that an attacker does not have an unlimited number of
authentication attempts he could use to guess an end user’s and
administrator 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.1a ensures that password rules, for password based
identification and authenticated, are enforced against all end
users, preventing the bypassing or circumventing security policies.
FIA_SOS.1b ensures that the passwords for administrators are of
a certain quality, to prevent easy to guess passwords being used.
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 53
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
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
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 54
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. FAU_STG.1 further prevents any other user than the
Directory Administrator from manipulating the 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.ENVMANAGE 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.ROUTE No dependency to any SFR.
OE.TIME FPT_STM.1 ensures that a reliable timestamp is provided by the
TOE environment.
The user attribute definition FIA_ATD.1 and verification of secrets
FIA_SOS.1a also depends on a reliable timestamp to maintain the
user attributes and to enforce the password policy.
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.
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 55
As the assurance components are those standard ones for EAL 4 augmented with
ALC_FLR.1, all dependencies for such EAL 4 assurance components are satisfied
automatically. For ALC_FLR.1 there are no dependencies to any other requirements.
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
FAU_STG.1 Protected audit trail storage FAU_GEN.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
FIA_AFL.1a Authentication failure handling FIA_UAU.1
FIA_AFL.1b Authentication failure handling FIA_UAU.1
FIA_ATD.1 User attribute definition Non explicit to FPT_STM.1
FIA_SOS.1a Selection of secrets Non explicit to FPT_STM.1
FIA_SOS.1b 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
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 56
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.
The FIA_AFL.1a and FIA_AFL.1b provides assurance by preventing password guessing
attacks against End User and administrator accounts, by blocking the account after a defined
number of failed attempts, thereby supporting the function FIA_UAU.1 that only provides
access to properly authenticated users.
FIA_ATD.1 and FIA_SOS.1 have non-explicit dependencies to a reliable time in order to
maintain the user attributes and to enforce the user password policy. This is addressed by
the TOE IT environment in FPT_STM.1 by providing reliable time stamps.
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. Manage-
ment of the replication relies on the access control FDP_ACC.2 and especially FDP_ACF.1.
FMT_MTD.1 restricts the ability to modify any other security relevant data, protecting against
tampering attacks through unauthorized modification of data.
FMT_SMF.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_SMF.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).
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.1a and FIA_SOS.1b reduce 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.
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 57
Table 7: Mapping of non-IT Security Requirements to Security Objectives for the
Environment
OE.MANAGE
OE.ENVMANAGE
OE.PHYSICAL
OE.DATABASE
OE.SOPHISTICATED
OE.BACKUP
OE.COMMUNICATION
OE.ROUTE
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
ER.ROUTE 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 assurance requirements
EAL 4 augmented with ALC_FLR.1 bring enough assurance elements for the TOE, operating
within its environment as described in this document. Furthermore, the EAL 4 assurance
level augmented with ALC_FLR.1 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.
8.3 TOESummarySpecificationRationale
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:
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 58
• 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
F.AUDIT
F.ACCESS_CONTROL
F.I&A
F.MANAGEMENT
F.REV_MEDIATION
FAU_GEN.1 X
FAU_GEN.2 X
FAU_SAR.1 X
FAU_SAR.2 X
FAU_STG.1 X
FDP_ACC.2 X
FDP_ACF.1 X
FIA_AFL.1a X
FIA_AFL.1b X
FIA_ATD.1 X
FIA_SOS.1a X
FIA_SOS.1b X
FIA_UAU.1 X
FIA_UID.1 X
FMT_MOF.1a X
FMT_MOF.1b X
FMT_MSA.1 X
FMT_MSA.3 X
FMT_MTD.1 X
FMT_SMF.1 X
FMT_SMR.1 X
FPT_RVM.1 X
Table 8shows 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
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 59
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
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 the Directory Administrator and Members of the
Administrative Group, preventing any other users to read the audit file.
FAU_STG.1 The requirement is satisfied by the function F.MANAGEMENT, which is
restricted only to Directory Administrators, preventing any other user to
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.1a
FIA_AFL.1b
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. For the
end users 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. For the administrators only the directory
administrator can specify the value applicable to all administrators.
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.1a
FIA_SOS.1b
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 constraints for a secure configuration are given. The
Directory Administrator and Members of the Administrative Group has the
ability to specify different values for the end users. The password policy for
the administrators can only be specified by the directory administrator.
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.
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 60
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.
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.
FAU_STG.1 is preventing the deletion of audit records, which is provided by FAU_GEN.1 by
any other user than the Directory Administrator.
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.1a,
FIA_AFL.1b, FIA_ATD.1, FIA_SOS.1a, FIA_SOS.1b, 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.1a and FIA_AFL.1b, 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.1a and
FIA_SOS.1b, preventing the user and administrator 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 are specified in
FMT_SMR.1.
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 61
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. Note that management of the
replication behavior is controlled by F.ACCESS_CONTROL. This relationship is done by a
dependency between FMT and FDP, instead as over FMT to F_ACCESS_CONTROL.
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.
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 medium (SOF-medium) which indicates that a
function provides adequate protection against straightforward or intentional breach of TOE
security by attackers possessing a moderate attack potential is consistent with the security
objectives of the TOE. This claim applies to identification and authentication as specified in
FIA_SOS.1a and FIA_SOS.1b, using the described settings, and satisfied by F.I&A.
8.4 Assurancemeasures rationale
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_AUT.1
ACM_CAP.4
ACM_SCP.2
ADO_DEL.2
ADO_IGS.1
ADV_FSP.2
ADV.HLD.2
ADV_IMP.1
ADV_LLD.1
ADV_RCR.1
AGD_SPM.1
AGD_ADM.1
AGD_USR.1
ALC_DVS.1
ALC_FLR.1
ALC_LCD.1
ALC_TAT.1
ATE_COV.2
ATE_DPT.1
ATE_FUN.1
ATE_IND.2
AVA_MSU.1
AVA_SOF.1
AVA_VLA.1
M.AUT X
M.CAP X
M.SCP X
M.DEL X
M.IGS X
IBM Tivoli Directory Server Version 6.0
Copyright IBM 2005 IBM CONFIDENTIAL Page 62
ACM_AUT.1
ACM_CAP.4
ACM_SCP.2
ADO_DEL.2
ADO_IGS.1
ADV_FSP.2
ADV.HLD.2
ADV_IMP.1
ADV_LLD.1
ADV_RCR.1
AGD_SPM.1
AGD_ADM.1
AGD_USR.1
ALC_DVS.1
ALC_FLR.1
ALC_LCD.1
ALC_TAT.1
ATE_COV.2
ATE_DPT.1
ATE_FUN.1
ATE_IND.2
AVA_MSU.1
AVA_SOF.1
AVA_VLA.1
M.FSP X
M.HLD X
M.IMP X
M.LLD X
M.RCR X
M.SPM X
M.ADM X
M.USR X
M.DVS X
M.FLR X
M.LCD X
M.TAT X
M.COV X X
M.FUN X
M.IND X
M.SOF X
M.VLA X X X