Tivoli Access Manager for Operating Systems 5.1
Security Target
Document Version Number 1.6.5
Document Creation Date: 2004-10-21
Document Update Date: 2006-02-01
Authors: Clemens Wittinger, David Ochel
Owner: Ron Willard
Note: This document will become a public document at the end of the evaluation
The responsibility for using the latest version of this document lies with the user of the document.
To request changes to this document, notify the document owner.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 2 2006-02-01
Table of Contents
1 ST introduction ......................................................................................................................................................... 6
1.1 ST Identification................................................................................................................................................. 6
1.2 ST Overview ....................................................................................................................................................... 6
1.3 CC Conformance Claim..................................................................................................................................... 7
1.4 Strength of Function........................................................................................................................................... 7
1.5 Definition of Terms............................................................................................................................................. 7
2 TOE Description ....................................................................................................................................................... 8
2.1 Abstract view: Access Control Framework according to ISO 10181-3 and the Open Group Authorization API
8
2.2 Mapping the TOE to the aznAPI System Structure........................................................................................... 10
2.3 Resource Manager (TAMOS RM) .................................................................................................................... 12
2.3.1 Authorization Component............................................................................................................................ 13
2.3.2 Audit Compontent........................................................................................................................................ 13
2.3.3 Login Component ........................................................................................................................................ 14
2.3.4 Commands Component................................................................................................................................ 14
2.3.5 Kernel Module............................................................................................................................................. 14
2.3.6 Authorization Flow...................................................................................................................................... 14
2.4 Authorization Evaluator................................................................................................................................... 15
2.5 Policy Server.................................................................................................................................................... 15
2.6 GSKit................................................................................................................................................................ 16
2.7 TOE configuration ........................................................................................................................................... 16
2.8 TOE User Types ............................................................................................................................................... 19
2.9 TOE Boundary ................................................................................................................................................. 19
2.10 TOE Security Model......................................................................................................................................... 20
2.10.1 Components............................................................................................................................................. 20
2.10.2 Security Functionality ............................................................................................................................. 21
3 TOE Security Environment ................................................................................................................................... 23
3.1 Assumptions...................................................................................................................................................... 23
3.2 Threats ............................................................................................................................................................. 24
3.2.1 Threats to be countered by the TOE ............................................................................................................ 25
3.2.2 Threat to be countered by the TOE environment......................................................................................... 26
3.3 Organizational Security Policies...................................................................................................................... 26
4 Security Objectives ................................................................................................................................................. 27
4.1 Security Objectives for the TOE....................................................................................................................... 27
4.2 IT Security Objectives for the Environment ..................................................................................................... 27
4.2.1 IT Security Objectives for the underlying operating system........................................................................ 27
4.2.2 IT Security Objectives for the LDAP server................................................................................................ 28
4.3 Non-IT Security Objectives for the Environment ............................................................................................. 28
5 IT Security Requirements ...................................................................................................................................... 30
5.1 Extended Components Definition..................................................................................................................... 30
5.1.1 FAU_GEN.3-TAMOS................................................................................................................................. 30
5.2 TOE Security Requirements ............................................................................................................................. 31
5.2.1 TOE Security Functional Requirements ...................................................................................................... 31
5.2.2 TOE Security Assurance Requirements....................................................................................................... 41
5.3 Security Requirements for the IT Environment ................................................................................................ 41
5.3.1 LDAP Server ............................................................................................................................................... 41
5.3.2 Underlying Operating System of the TOE components (Policy Server) ..................................................... 44
5.3.3 Underlying Operating System of the TOE components (TAMOS RM)...................................................... 45
5.4 Strength of Function (SOF) Claim ................................................................................................................... 47
6 TOE Summary Specification ................................................................................................................................. 48
6.1 Statement of TOE Security Functions............................................................................................................... 48
6.1.1 F.Audit......................................................................................................................................................... 48
6.1.2 F.Authentication .......................................................................................................................................... 49
6.1.3 F.Authorization............................................................................................................................................ 51
6.1.4 F.Management ............................................................................................................................................. 62
6.1.5 F.Communication ........................................................................................................................................ 66
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 3 2006-02-01
6.2 TSF that are subject to a Strength of Function Analysis.................................................................................. 66
6.3 Statement of Assurance Measures.................................................................................................................... 66
7 PP claims.................................................................................................................................................................. 69
8 Rationale.................................................................................................................................................................. 70
8.1 Security Objectives Rationale .......................................................................................................................... 70
8.1.1 Security Objectives Coverage...................................................................................................................... 70
8.1.2 Security Objectives Sufficiency................................................................................................................... 71
8.2 Security Requirements Rationale ..................................................................................................................... 73
8.2.1 Security Requirements Coverage................................................................................................................. 73
8.2.2 Security Requirements Sufficiency.............................................................................................................. 77
8.2.3 Security Requirements Dependencies.......................................................................................................... 79
8.2.4 Internal Consistency and Mutual Support.................................................................................................... 83
8.2.5 Evaluation Assurance Level and Strength of Function................................................................................ 85
8.3 TOE Summary Specification Rationale............................................................................................................ 85
8.3.1 Security Functions Justification................................................................................................................... 85
8.3.2 Justification that the Security Functions are mutually supportive ............................................................... 88
8.4 PP Claims Rationale........................................................................................................................................ 89
9 Abbreviations .......................................................................................................................................................... 90
10 Glossary............................................................................................................................................................... 91
11 References ........................................................................................................................................................... 96
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 4 2006-02-01
History
This track of document changes is a part of the standard document tracking process.
Version Date Summary of Changes
0.1 2004-08-12 First version after draft reviews
0.2 2005-04-05 Work in progress at beginning of evaluation project: moved to CC
2.2; clarified usage of “users” and “administrators” throughout
document; added boundary/component diagram; further completion
of TOE configuration and underlying systems; identification of
guidance; resolved redundancies in SPD and added threat against
separation, further specified threat agents and assets; added
O.SOF and OE.SEPARATION; removed support of TLSv1; re-
moved FIA_UAU.1, FIA_UAU.5; splitted SFRs for underlying PS
and RM systems; removed SFRs for non-IT environment; updated
mapping tables in rationale; clarifications and augmentations in all
chapters.
0.3 2005-04-14 Changes to evaluated configuration in 2.7; introduced A.PAM; clari-
fied credential derivation in FIA_USB.1; refined FIA_USB.1
0.4 2005-04-27 Corrected section 1.2; editorial changes in 2.2; removed redundan-
cies and provided clarifications in 2.7; clarified assets in 3.2; cor-
rected application notes for FAU_SAR.1(2), FIA_AFL.1(2); updated
password policy in FIA_SOS.1; refined SFRs in 5.2 to reflect IT
environment; clarified access control support in 5.2.3; updated 5.3;
clarifications in 6.1.2; correction in 6.1.3.9; updated 6.1.4.1 and
6.1.4.8; added “TOE environment” to glossary; further editorial
changes.
0.5 2005-04-27 Clarification in 2.2; allow usage of pdadmin from TAMOS RM in
2.5, A.ADMIN; allow LDAP replicas in 2.7; throughout ST clarifica-
tion that LDAP supports the authentication of administrators and
the TOE enforces it; corrected identification of operations in chap-
ter 5; corrected FAU_SEL.1(2); removed FAU_STG.4; updated
8.2.1; completed 8.2.2, 8.2.4 and following chapters; various edito-
rial changes.
0.6 2005-05-02 Added clarifications on LDAP support for administrator authentica-
tion and assumptions for the support of LDAP replicas
(A.FRIENDLY_LDAP, A.DIR_PROT, OE.FRIENDLY_DS,
OE.REPLICAS).
0.7 2005-05-06 Editorial changes.
0.8 2005-05-18 Changes due to evaluation results.
0.9 2005-05-25 More changes due to evaluation results.
1.0 2005-06-06 Improved mapping for A.FRIENDLY_OS and performed refine-
ments on FPT_SEP.1 and FPT_STM.1 for the IT environment to
clarify the TOE’s dependency on the specified mechanisms.
1.1 2005-06-15 Clarified kernel versions in section 2.7.
1.2 2005-07-22 Corrected version of HP UX in 2.7. Added various user space pro-
grams to 6.1.3.10 and 6.1.4.8. Augmented OE.SEC_INTEGRATE
to address protection of communication with LDAP server.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 5 2006-02-01
1.3 2005-08-03 Changed TAMOS fixpack level and SLES kernel versions in 2.7.
1.4 2005-10-10 Updates with regard to the evaluated configuration.
1.5 2005-10-11 Further clarifications with regard to the evaluated configuration in
section 2.7
1.6 2005-11-04 Addressing comments from CB. Further adaptations to product ca-
pabilities.
1.6.1 2005-11-07 One typo is fixed.
1.6.2 2005-11-17 Clarified PS/RM selection in 2.7.
1.6.3 2005-11-17 Added Release Notes to TOE in 2.7; Changed FIA_AFL.1(1) and
(2) to define minimum lockout period to match SOF analysis.
1.6.3 2005-12-14 Approved by Ron Willard. Official approval notice posted in the
AMOS 2003 Teamroom
1.6.4 2006-01-25 Corrected typo in 6.1.3.1; added note on component leveling in
section 5.1.1.
1.6.4 2006-01-27 Approved by Ron Willard. Official approval notice posted in the
AMOS 2003 Teamroom
1.6.5 2006-02-01 Fixed enumeration in SFRs.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 6 2006-02-01
1 ST introduction
This document defines the Security Target for the Common Criteria evaluation of Tivoli Ac-
cess Manager for Operating Systems, developed by International Business Machines Cor-
poration (IBM). The sponsor for this evaluation at assurance level EAL3 is IBM.
1.1 ST Identification
Title: Tivoli Access Manager for Operating for Systems 5.1 Security Target, Version 1.6.5
Keywords: Access Control, ISO 10181-3, aznAPI
1.2 ST Overview
IBM Tivoli Access Manager for Operating Systems is a specific implementation of the ac-
cess control framework defined by the ISO 10181-3 [ISO 10181-3] standard and the Au-
thorization API (aznAPI) [AZNAPI].
Throughout the document the following terminology will be used to identify the TOE and its
subsystems:
• “TAMOS product”, “TOE” - IBM Tivoli Access Manager for Operating Systems
• “TAMOS”, “TAMOS Resource Manager”, “TAMOS RM” - the Resource Manager (see
section 2.3)
• “Policy Server” - the Policy Server
The TOE is an authorization solution for operating systems. The TOE's authorization ser-
vices allow an organization to securely control user access to protected information and re-
sources. By providing a centralized, flexible, and scalable access control solution, the TOE
allows highly secure and well-managed operating systems infrastructures to be built.
In addition to its state-of-the-art security policy management feature, the TOE supports au-
thentication decision enforcement for administrative users, the application of login and
password policies to user accounts of underlying resources, authorization, data security, se-
cure communication and resource management capabilities.
At its core, the TOE provides role based access control: the Tivoli Access Manager authori-
zation service, accessed through a standard authorization API, provides permit and deny
decisions on access requests from native Tivoli Access Manager resource managers, such
as the TAMOS Resources Manager, and third-party applications.
The TAMOS RM is part of the TOE. It is the resource manager/authorization evaluator re-
sponsible for managing and protecting operating systems information and resources – it ap-
plies a centrally managed authorization and authentication policy to operating system re-
sources. The following features are provided by the TAMOS RM:
• Authentication Policy Services – extends the native operating system authentication
process by applying centrally managed login and password policies.
• Access control – protects operating system resources like files, directories, programs
against unauthorized access.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 7 2006-02-01
1.3 CC Conformance Claim
This Security Target is based upon the
Common Criteria for Information Technology Security Evaluation, January 2004, Version
2.2, Part 1-3, CCIMB-2004-01-001, CCIMB-2004-01-002, CCIMB-2004-01-003 [CC]
For the evaluation, the following methodology is used:
Common Methodology for Information Technology Security Evaluation, January 2004, Ver-
sion 2.2, CCIMB-2004-01-004 [CEM]
This Security Target is
• Part 2 extended
• Part 3 conformant
The evaluation assurance level is EAL3, augmented by ALC_FLR.1
1.4 Strength of Function
The claimed strength of function for this TOE is: SOF-medium
1.5 Definition of Terms
Authorized users Individuals who have been successfully identified by the TOE
and may access resources as defined by the access control
policy of the TOE. This includes “unauthenticated” users where
the TOE policy allows unauthenticated users access to re-
sources. See also “Note”.
Unauthenticated users Individuals who can not be identified by the TOE but are part of
the user community allowed to access resources available to
unauthenticated users. Note that all users of resources will be
authenticated by the underlying operating system – the fact
that the TOE does not recognize them as individual users
makes them “unauthenticated” users from the perspective of
the TOE. See also “Note”.
Base administrators Individuals who have successfully authenticated themselves to
the TOE as administrators and are allowed to perform adminis-
trative tasks via the pdadmin interface commands within their
administrative responsibilities. See also “Note”.
Resource Manager
administrators / TAMOS
RM administrators
Individuals who have been successfully authenticated by the
underlying operating system and have been identified by the
TOE as administrators are allowed to perform administrative
tasks via the TAMOS RM management commands within their
administrative responsibilities. See also “Note”.
Note: Administrators and
Users
Note that in the definition of the SFRs in chapter 5 the terms
(a) “users” and (b) “administrators” are used to distinguish
between (a) all users of the managed resource, including TA-
MOS RM administrators and (b) Base administrators only, if
not noted otherwise.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 8 2006-02-01
2 TOE Description
The TOE consists of IBM Tivoli Access Manager for Operating Systems, Version 5.1 (TA-
Mos). The following sections provide a description of the structure of the TOE, its bounda-
ries, and an overview of the security functions provided by the TOE.
2.1 Abstract view: Access Control Framework according to ISO 10181-3 and the
Open Group Authorization API
The TOE is a specific implementation of the access control framework defined by the ISO
10181-3 [ISO 10181-3] standard and the Authorization API (aznAPI) [AZNAPI]. The TOE
uses the overall access control model and the interface described in those two standards.
To explain those ideas we provide a short summary of them.
ISO 10181-3 contains the following figure to explain the general access control model:
Figure 1: ISO 10181-3 fundamental access control functions
In this model an initiator submits an access request to the “Access Enforcement Function”
(AEF) of a system. This function passes the request to an “Access Decision Function”
(ADF), which makes the decision based on the rules of the access control system which
may be based on:
• The identity and attributes of the initiator
• The identity and attributes of the resource being requested
• Contextual information (e. g. time and date, number of request from the same initiator, in-
formation from other systems)
Separating the access enforcement from the access decision function, as well as separating
the access enforcement function from the actual target, allows the implementation of highly
flexible access control and management systems in distributed environments. ISO 10181-3
actually is a general framework for such kind of access control and management system.
The Open Group now defines a standard for an application programming interface (API) for
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 9 2006-02-01
the interface between the Access Enforcement Function (AEF) and the Access Decision
Function (ADF) which allows AEF and ADF components from different vendors to co-
operate. The following figure shows the aznAPI system structure as defined in [AZNAPI]:
Figure 2: aznAPI System Structure as defined in the Open Group Standard
In this model the initiator submits his access request to the AEF, which then (if required by
the policy) authenticates the identity of the initiator using the authentication service within
the AEF. This authentication service may use an external authentication mechanism (e. g. a
directory server storing user attributes and credentials).
The request together with the initiator attributes is then passed via the aznAPI interface to
the implementation of the aznAPI, which in turn may store or request from an external entity
additional security attributes of the initiator of the request. The attributes together with the in-
formation passed via the aznAPI about the request (including the target of the request) as
well as the information about the initiator of the request is passed to the ADF component,
which uses the Access Control Policy Rules stored in some kind of database.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 10 2006-02-01
2.2 Mapping the TOE to the aznAPI System Structure
The TOE is a specific implementation of the access control model defined in [ISO 10181-3]
and [AZNAPI]. The overall TOE architecture and boundaries are illustrated in figure 3. With
relation to the model defined in figure 2 the TOE includes the Access Enforcement Function
(AEF) and the Access Decision Function (ADF) together with the Access Control Policy
rules. The Authentication Mechanism for users is implemented in the IT environment (the
TOE relies on the underlying operating system), while TOE administrators are authenticated
by the TOE with the help of an LDAP user registry in the IT environment. The “Initiator Se-
curity Attributes” are stored in this LDAP user registry. Also, the target system which hosts
the actual resources that are to be protected is not part of the TOE.
In this model a user submits a request for a resource (e. g. accessing a file that is protected
by the TOE). This request is intercepted by the TOE, which implements access control
checking on top of the native operating system functions. The TOE performs the following
actions:
• Checking if the requested resource is known to be not protected. If this is true, the re-
quest is passed through to the operating system.
• Checking if the user has the right to access the requested resource for the requested op-
eration. If not, the request is rejected. If yes, the request is passed through to the under-
lying operating system.
To explain how the access rights are checked an overview on the Tivoli Access Manager
components is provided first (please see figure 3 for an architectural overview of the TOE).
The “Resource Manager” is implemented as part of the TOE by the TAMOS RM. This com-
ponent includes also the “Authorization Evaluator” as a subsystem. The Resource Manager
communicates with the “Authorization Evaluator” via the aznAPI.
The “Policy Server” is responsible to define and maintain the access control policy. It uses
the “Master Authorization Policy” database to store the access control policy rules.
To speed up the time required to make an access decision, the “Authorization Evaluator”
manages a replica of the “Master Authorization Policy”. The Policy Server informs all Au-
thorization Evaluators about modifications to the “Master Authorization Policy” (actually what
it does is to use a standard compression utility to compress the whole database and then
transfer the whole new database). An Authorization Evaluator can also request the Policy
Server to submit a new copy of the Master Authorization Policy (which it does upon startup,
since there may be updates it could not obtain e.g. during a down-time). Also the Policy
Server can request an Authorization Evaluator to update the replica of the Master Authoriza-
tion Policy to make sure that the Authorization Evaluator has the latest version.
Administration of the TOE is performed via a workstation or terminal directly connected to
the Policy Manager component. Only the command line interface and C language API for
administration are part of the evaluated configuration. The C language API may be used by
an organization to define its own tools to automate some of the administration tasks. But
such tools would then be part of the IT environment and it is the responsibilty of the con-
sumer to ensure that those tools perform their task correctly.
The TAMOS RM can be further managed by commands provided by the TAMOS RM.
These commands can be initiated by an appropriately authorized user logged into the un-
derlying operating system the TAMOS RM is running on.
Administration includes the management of the Master Authorization Policy (defining access
rules for protected objects) as well as management of the TOE. It should be noted that ac-
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 11 2006-02-01
cess rights of administrators to administrative objects of the TOE are also stored and main-
tained in the Master Authorization Policy; this specifically includes the management com-
mands provided by the TAMOS RM.
To enhance authentication capabilities the TOE uses modules that extend the native au-
thentication process of the host operating system by applying a login policy defined within
the TOE.
For administrator authentication, the TOE uses a directory server. The directory server pro-
vides a repository for user and administrator attributes and credentials. Authentication of
users is done by the Resource Manager in combination with host operating system, authen-
tication of administrators is performed by the Policy Server (in the sense of the authentica-
tion service in figure 2) and uses the external Directory Server as the authentication mecha-
nism.
The communication link between the TOE and the LDAP server is protected using the SSL
v3 protocol. The TOE uses the GSKit library for the implementation of those protocols and
their underlying cryptographic functions. The GSKit library is therefore part of the Policy
Server and part of the Resource Manager. Also, the communication link between the Policy
Server and the different Resource Managers is secured by SSL v3 using the GSKit library.
The Master Authorization Policy as well as the Replica Authorization Policy are databases.
The Master Authroization Policy is a database held by the Policy Server and the Replica Au-
thorization Policy is a database held by each Authorization Evaluator.
Underlying Hardware
Operating System
Underlying Hardware
Operating System
kernel
syscall
IF
TAMos kernel
module
authorization
daemon
authentication
module
auditing
administrative
commands
login
Resource User
Administrator
Replica
Policy
Master
Policy
LDAP
repository
Policy Server
C API
administrative
commands
Policy Server Resource Manager
runtime
LDAP client
GSKit
aznAPI
(Authorization
Evaluator)
runtime
LDAP client
GSKit
Figure 3: TOE components and boundary –TOE parts are displayed without color (white), the parts of
the TOE environment are gray. The dashed line depicts the information flow during policy synchroni-
zation.
The TOE architecture (showing also the directory server and the servers holding the re-
sources, although they are not part of the TOE) is shown in Figure 3. Please refer to Figure
4 for detailed schematics of the resource manager (section 2.3)
The TOE now maps in the following way to the system structure shown in Figure 2 as de-
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 12 2006-02-01
fined in [AZNAPI]:
• The “Initiator” maps to the client
• The “Access Enforcement Function” (AEF) and the “Authentication Service” map to the
Resource Manager (part of TAMOS RM)
• The “Access Decision Function” (ADF) maps to the “Authorization Evaluator” (part of
TAMOS RM)
• The “aznAPI” maps to the “aznAPI”
• The “aznAPI” implementation maps to the “Authorization Evaluator” and the “Policy
Server”.
• For administrative authentication within the “Policy Server”
o The “Authentication Mechanism” and the “Initiator Security Attributes” map to the
“Directory Server” (which is not part of the TOE but part of the TOE environment)
• For user authentication within the “Resource Manager” (part of TAMOS RM)
o The “Authentication Mechanism” maps to the underlying operating system
o The “Initiator Security Attributes” maps to the “Directory Server” and the “Policy
Server”
• The “Access Control Policy Rules” map to the “Master Authorization Policy” and the
“Replica Authorization Policy”
• The “Target” maps to the “Target”
2.3 Resource Manager (TAMOS RM)
The Resource Manager shown in the previous figure as part of the TOE is responsible to
protect the resources on the host system (operating system resources).
TAMOS RM
Authorization
Component
TAMOS RM
Audit Component
TAMOS RM
Login Component
aznAPI – Authorization
Evaluator
TAMOS RM
Kernel Subsystem
Operating System
Kernel
(Kernel Space)
User Space
System Call Interface
User
User
TAMOS RM
Commands
User
Native System
Call
Figure 4: Resource Manager Structure
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 13 2006-02-01
Figure 4 shows the structure of TAMOS RM comprising
• The TAMOS RM authorization component
• The TAMOS RM login component
• The TAMOS RM audit component
• The TAMOS RM commands component
and
a. The TAMOS RM kernel subsystem
all of which are part of the TOE.
The authorization mechanism of the TOE is capable of performing and enforcing access
control decisions for users of a managed resource with respect to the following object types:
b. file system resources
c. outgoing and incoming network connections
d. login and password control services
e. changes of user and group identity
f. sudo commands
2.3.1 Authorization Component
The Authorization Daemon (pdosd) is a multi-threaded daemon process that processes all
authorization requests for the TAMOS RM. Authorization requests are initiated when the
kernel intercepts a system call and sends a request for an authorization decision to the
pdosd daemon. The pdosd daemon processes that request and sends a decision of permit
or deny back to the kernel, which, in turn, either allows the system call to continue or returns
an error to the caller.
The pdosd daemon relies on the Authorization Evaluator (aznAPI) to manage and store the
security policy in the policy database. The pdosd daemon also uses the Tivoli Access Man-
ager user registry (LDAP) for storage and retrieval of user credentials, which are used when
making an access decision.
Users do not authenticate directly to the TAMOS RM, but TAMOS RM extends the operating
system authentication process (see section 2.3.3).
When a user logs into a TAMOS RM protected endpoint (i.e. the underlying operating sys-
tem), after the user has successfully been authenticated by the native authentication
mechanism, the user’s credentials are retrieved from the user registry via the aznAPI.
2.3.2 Audit Compontent
The TOE provides auditing for security-relevant events. TAMOS RM provides extensive au-
diting capabilities. Audit levels can be set globally, for a specific protected resource, or on a
per-user basis. For global- and resource-level auditing, the permit and deny levels can be
further qualified so that they are only in effect for specified TAMOS RM actions. All of the
TAMOS RM components as well as the commands generate audit data.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 14 2006-02-01
2.3.3 Login Component
The Login Component of TAMOS RM is used to enforce the login and password policies
that are supported by TAMOS RM. The mechanism that is used to insert TAMOS RM's login
subsystem in the login path to allow further authorization decisions is a loadable authentica-
tion module on AIX and a pluggable authentication module (PAM) on all other supported
platforms.
The supported policies allow to define time-of-day restrictions, restricting login to individual
local and remote terminals, and login-activity-related policies such as password expiry,
automatically disabling accounts after a number of consecutive failed logins, and automati-
cally disabling inactive accounts.
2.3.4 Commands Component
The commands component of TAMOS RM consists of administrative commands that are
used to manage, view, modify, or control various aspects of the TAMOS RM.
2.3.5 Kernel Module
The TAMOS kernel module intercepts system calls and enforces policy defined within the
TOE on the actions being performed (see section 2.3.6).
2.3.6 Authorization Flow
1. An operating system resource is being accessed by a caller.
2. The TAMOS Kernel Module intercepts the system call and checks to determine if the ob-
ject the call is trying to access is subject to policy by means of querying the TAMOS Au-
thorization Component or using a local cache. If not, the TAMOS Kernel Subsystem
passes control to the native operating system call.
3. The kernel sends a request to the TAMOS Authorization Component, passing on the ac-
cessing user’s identification, the type and name of the operating system object, the action
being performed and the executable used to perform the action.
4. The TAMOS Authorization Component uses this information from the kernel to retrieve
relevant user credentials, construct the protected object name, and map the specified ac-
tions to the relevant TAMOS RM permissions. It then calls the Authorization Evaluator
with this information to determine if this access should be allowed.
5. The Authorization Evaluator returns an access decision. The TAMOS Authorization
Component uses this information to make a final decision if access should be allowed.
6. An audit record is eventually generated indicating, amongst others, the object, the initia-
tor, the operation and the outcome of the decision.
7. The TAMOS Authorization Component passes the result back to the TAMOS Kernel
Module.
8. The TAMOS Kernel Module, depending on the result, denies the request signalling an er-
ror condition to the caller, or passes the request to the native operating system call im-
plementation.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 15 2006-02-01
2.4 Authorization Evaluator
This component is running as a part of a TAMOS RM system. When the Resource Manager
(TAMOS RM) calls functions of the aznAPI to check if the client has the right to access the
resource in the intended way, the Authorization Evaluator will check the local Replica Au-
thorization Policy to decide if the request can be granted or not.
The Authorization Evaluator is also responsible for synchronizing the local replica of the
Master Authorization Policy with the Policy Server. The Authorization Evaluator provides a
mechanism to ask the Policy Server if its version is still up-to-date (which it always does on
start-up and continuously during operation) and will store a new version of the replica data-
base on demand of the Policy Server. In addition the Authorization Evaluator will serve addi-
tional system management commands coming from the Policy Server.
The Authorization Evaluator sets up a secured communication channel with the Policy
Server using the SSL v3 protocol with client and server authentication. The Policy Server
will take the role of the server while the Authorization Evaluator will take the role of a client.
Before an Authorization Evaluator can set up such a communication channel, it needs to
have its public key certified by the Policy Server (which acts as a certification authority for
SSL client certificates within the TOE).
2.5 Policy Server
This component is responsible for the management of the Master Authorization Policy. It
provides a separate interface for administrators (pdadmin interface) as a command line in-
terface as well as a C API on the Policy Server. To perform administrative actions an admin-
istrator has to identify and authenticate via these interfaces. Only password based authenti-
cation is possible at this interface.
An administrator using a remote terminal or remote workstation to connect to the Policy
Server for administration must ensure that the remote terminal or workstation is in a secured
environment and managed securely. Management is performed by setting up a secured
connection to communicate with a shell of the operating system on the Policy Server. There
the administrator invokes the pdadmin command line interface and authenticates him- or
herself to the TOE. Note that the security measures to protect the remote terminal or remote
workstation as well as the security measures used to protect the communication link be-
tween the remote terminal or workstation are not part of the TOE but have to be assured in
the TOE environment. Alternatively, administrators can invoke the pdadmin command on a
TAMOS RM.
Administrators can now define and/or modify rules in the Master Authorization Policy as well
as perform administrative actions for the remote Authorization Evaluator or Resource Man-
ager components. Whenever administrators modify the Master Authorization Policy, a re-
quest is sent to all Authorization Evaluator components for synchronization of their replica
database.
The Policy Server uses the Master Authorization Policy to store access control rules for sys-
tem management objects and uses the Directory Server to store attributes and credentials
for administrators. Management of the TOE can only be performed via the pdadmin inter-
face of the Policy Server, since the “management objects” are not known to the Resource
Manager or the Authorization Evaluator.
The Policy Server generates audit records for administrative actions.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 16 2006-02-01
2.6 GSKit
GSKit is a library that implements the SSL Version 3 protocol to secure the communication
between the TOE and other trusted systems (including the LDAP server) as well as the
communication between distributed parts of the TOE. SSL is also used to secure the com-
munication between the TOE and client systems. GSKit is part of each Resource Man-
ager/Authorization Evaluator system as well as the Policy Server. Since it provides functions
to secure the communication between the involved machines, it is part of the TSF. On the
Policy Server this component also provides the functions to generate and sign the certifi-
cates for the public keys of the TOE.
The functions provided by GSKit include those required for the generation of public/private
RSA key pairs, generation of X.509 V3 certificate and certificate management (signing, dis-
tribution and revocation). RSA key pairs are required for the SSL ciphersuites supported by
the TOE.
Within the TOE the Policy Server component is used as a Certification Authority for the cer-
tificates of the other TOE components. When a new TAMOS RM system is added to the
TOE, during the installation of those components an RSA key pair is generated and the key
pair and the PDCA certificate (the CA certificate of the Policy Server) is imported via the
pdadmin interface. Afterwards the new TAMOS RM system and the Policy Server compo-
nent can set up a trusted communication path with mutual authentication using the SSL v3
protocol with client and server authentication.
2.7 TOE configuration
The following describes the specifics of the configuration of Tivoli Access Manager for Op-
erating Systems, Version 5.1 that conforms to the description in this Security Target and is
henceforth called the evaluated configuration:
a. The evaluated configuration has one Policy Server system and one or more Resource
Manager/Authorization Evaluator systems:
o The Policy Server component of the TOE is installed and operated on a dedi-
cated system within a physically protected environment. Optionally, the TAMOS
RM can be installed on the Policy Server.
o Resource Manager and Authorization Evaluator are always installed and oper-
ated on the same system. The evaluated configuration does not include Authori-
zation Evaluator components running on a machine separate from the Resource
Manager that uses them.
o All Resource Manager/Authorization Evaluator systems operate independent
from each other and are only connected to the central Policy Server.
o The Policy Server and all the Resource Manager/Authorization Evaluator sys-
tems only use the operating systems platform combinations as defined in Table
1.
b. The following components and/or configurations are not part of the evaluated configura-
tion and must not be used:
o The use of the Web Portal Manager and integration with the Tivoli Desktop for
the administration of the TOE is not supported. Instead only the command line in-
terfaces of pdadmin and TAMOS RM and the pdadmin C API are supported in
the evaluated configuration.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 17 2006-02-01
o No Application Development Kit is installed.
o Active Directory is not supported. Only LDAP is supported as interface to the
user registry. Multiple LDAP replicas are supported, whereas the number of
LDAP masters in the environment is restricted to one.
o No hardware encryption device is used. The cryptographic services are fully pro-
vided by the software implementation of the GSKit component.
o Language packs other than English are not supported. Only the English lan-
guage pack for the TOE is evaluated.
o Non-certified authentication mechanisms and non-password based authentica-
tion mechanisms are not supported. On underlying operating systems managed
by TAMOS RM the TOE supports only password-based authentication mecha-
nisms listed in the Administrator Guide for the TAMOS ROM as being certified.
For administrators requesting access via the pdadmin interface for the Policy
Server, only password-based authentication is supported.
o Weak or no encryption of internal communications. Communication between the
LDAP server and the TOE as well as the communication between the Policy
Server and the Resource Manager/Authorization Evaluator systems is protected
using the SSLv3 protocol with one of the ciphersuites defined in this Security
Target. The use of unencrypted communication is disabled in the TOE.
c. The following components of the TAMOS product are not evaluated as part of the TOE,
but can be used and are then considered part of the IT environment:
o the log router daemon operating on the audit log files for remote distribution
o the Tivoli Enterprise Console daemon providing audit data for remote access
d. The following components of the TAMOS product are part of the TOE, but do not contain
security functionality that is subject to evaluation:
o the integrated Watchdog functionality of the TOE
o The TCB mechanisms of the TAMOS product, such as checksum verification of
files being defined as a member of the TCB,
To set up the evaluated configuration compliant with the description above the user needs
to follow the guidance provided in the TAMos 5.1 Common Criteria Guide.
The system components to be installed are:
1. Policy Server:
a. Global Security Toolkit (GSKit) 7.0.3.3
b. Tivoli Directory Server 5.2 Client
c. Tivoli Access Manager 5.1 runtime
d. Tivoli Access Manager 5.1 policy server
e. Fixpack 06 for Tivoli Access Manager 5.1
2. Resource Manager/Authorization Server (TAMOS RM)
a. Global Security Toolkit (GSKit) 7.0.3.3
b. Tivoli Directory Server 5.2 Client
c. Tivoli Access Manager 5.1 runtime (including the authorization evaluator)
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 18 2006-02-01
d. Tivoli Access Manager for Operating Systems 5.1
e. Fixpack 06 for Tivoli Access Manager 5.1
f. Fixpack 17 for Tivoli Access Manager for Operating Systems 5.1
With one exception, noted in the table below, the Policy Server and all Resource Man-
ager/Authorization Evaluator within an evaluated configuration use the same operating sys-
tem platform as underlying system (but may run on different machines). The platforms with
their corresponding TAMos resource manager modules that are covered by this evaluation
are the following:
• IBM AIX 5.2
a. 32-bit (SMP / UP)
b. 64-bit (SMP / UP)
• Sun Solaris 2.8
a. 32-bit (SMP / UP)
b. 64-bit (SMP / UP)
• HP-UX 11i V1
a. 64-bit (SMP / UP)
• RedHat Enterprise Linux AS/WS Version 3 Update 2 on i386 architectures (RHEL3)
a. kernel-2.4.21-15.EL.i686.rpm (UP)
b. kernel-smp-2.4.21-15.EL.i686.rpm (SMP)
• Novell SUSE Linux Enterprise Server 8 Service Pack 3 on i386 architectures (SLES8)
a. k_deflt-2.4.21-295.i586 (UP)
b. k_smp-2.4.21-295.i586 (SMP)
Resource Manager(s) can be run in arbitrary combinations of their variations listed above,
e.g. it is permitted to operate a Policy Server on AIX 5.2.with Resources Managers running
on AIX 5.2 32-bit SMP, AIX 5.2 32-bit UP, AIX 5.2 64-bit SMP and AIX 5.2 64-bit UP in the
same environment.
This yields to the system combinations outlined in the table below being covered by this
evaluation.
Combination Policy Server TAMOS Resource Manager(s)
1 AIX 5.2 AIX 5.2
2 Solaris 2.8 Solaris2.8
3 HP-UX 11i HP-UX 11i
4 RHEL3 RHEL3
5 SLES8 SLES8, Solaris 2.8 (64bit SMP/UP)
Table 1: Valid Platform Combinations
The following guidance documents are part of the TOE:
• IBM Tivoli Access Manager for Operating Systems Release Notes
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 19 2006-02-01
• IBM Tivoli Access Manager for Operating Systems Installation Guide
• IBM Tivoli Access Manager for Operating Systems Administration Guide
• IBM Tivoli Access Manager for Operating Systems Problem Determination Guide
• IBM Tivoli Access Manager Base Installation Guide
• IBM Tivoli Access Manager Base Administration Guide
• IBM Tivoli Access Manager for e-business Release Notes
• IBM Tivoli Access Manager for e-business Administration C API Developer Reference
• IBM Tivoli Access Manager for e-business Command Reference
• IBM Tivoli Access Manager Error Message Reference
• IBM Tivoli Access Manager for e-business Problem Determination Guide
• IBM Global Security Kit Secure Sockets Layer Introduction and iKeyman User’s Guide
2.8 TOE User Types
The TOE deals with several logically distinct types of users:
1. Administrative users (“administrators”)
a. Base administrators managing the central policy using the pdadmin command
or the administration C API. These users are authenticated by the Policy Server
in combination with the LDAP server.
b. Resource manager administrators using the administrative commands on the
TAMOS resource manager. Those are specifically authorized operating system
users that are able to manage TAMOS RM specific aspects. They are authenti-
cated by the native operating system's mechanisms. The authorization of these
administrators is managed by the TOE using its central policy.
2. Non-administrative users (“users”)
a. Resource users accessing the operating system resources. These users are
authenticated by the native operating system's mechanisms. TAMOS RM applies
a centrally managed login policy to the native operating system login process.
The authorization of these users is managed by the TOE using the central policy.
Note that from a technical point of view there is no distinction between administrative and
non-administrative users, they are commonly referred to as users. The distinction is made
on the logical level based on the fact whether users are privileged to perform administrative
tasks for the TOE or not. To this extent, “root” users on the underlying operating system re-
source are non-administrative users from the TOE’s perspective.
Note also that in the definition of the SFRs in chapter 5 the terms (a) “users” and (b) “ad-
ministrators” are used to distinguish between (a) all users of the managed resource, in-
cluding TAMOS RM administrators and (b) Base administrators only, if not noted otherwise.
2.9 TOE Boundary
Figure 3 shows the boundary of the TOE. It shows that the Policy Server, the. Resource
Manager/Authorization Evaluator, the Master Authorization Policy database and the Replica
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 20 2006-02-01
Authorization Policy database are part of the TOE. It also shows that the host operating sys-
tem, the LDAP server and the managed resources (client operating systems) are all part of
the TOE environment.
2.10 TOE Security Model
2.10.1Components
The TOE Security Model has the following components:
1. A User Registry (LDAP)
The user registry contains all users and groups allowed to participate in the Tivoli Access
Manager secure domain.
Note: The LDAP Server is not part of the TOE!
2. A Master Authorization Policy Database
This database contains a representation of all resources in the domain (= protected ob-
ject space). The security administrator can define Access Control Lists (ACL) and Pro-
tected Object Policies (POP) and Access Control Extended Attributes for those resources
that require protection.
3. An Authentication Policy Service (TAMOS RM)
This service extends the verification of the claimed identity of a user by applying a login
policy that takes into account various attributes stored in the user registry and policy da-
tabase. The user's identification information is obtained from the User Registry. If a user's
authentication information could not be obtained from the User Registry, this user is
treated as unauthenticated by TAMOS RM.
Note: The login policy does not cover the verification of the user's authentication secrets.
4. An Administration Authentication Service (Policy Server)
This service verifies the claimed identity of a Base administrator. All administrators that
are going to be authenticated must have an entry in the User Registry.
When an administrator is successfully authenticated a set of identification information
(credentials including user identity, group membership and security attributes) is ex-
tracted from the information stored in the User Registry and maintained for the user
within the TOE.
5. An Authorization Service
For each attempted access this service verifies if the user attempting access has the
right to access the resource in the intended way. This is done by comparing the user’s
credentials with the rules defined for the resource in the Authorization Policy Database.
The Authorization Service is called by the Resource Manager and returns “yes” or “no”
depending on the evaluation of the rules from the database.
For Resource Manager Administrators and Resource Users the Authorization Evaluator
creates the user credentials used in the TOE’s authorization evaluation by deriving the
user name from the underlying system’s user registry by using the users’ numerical ID in-
tercepted during login and matching this user name to the corresponding entry in the pol-
icy data base.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 21 2006-02-01
6. An Audit Service
A configurable number of events will generate an audit record that allows tracing of the
time the event happened and the user that caused the event.
7. An Administration Interface for the Policy Server
This interface is used to administer the Policy Server and the central authorization policy.
8. An Administration Interface for TAMOS RM
This interface is used to administer specific security functions of the TAMOS RM.
9. Configuration Files
A number of configuration files are used by the components of the TOE. The settings of
those files define the behavior of the security functions of the TOE. Configuration files
need to be defined correctly at the installation time of the TOE to ensure a secure initial
configuration. The administrator will maintain configuration files by:
1. Using the administration commands of the pdadmin interface (Policy Server).
2. Directly modifying the files (Policy Server).
3. Using administrative commands (TAMOS RM).
2.10.2Security Functionality
The TOE has the following security functionality:
1. Authentication of Base administrators
Administrators allowed to administer the TOE via the pdadmin interfaces (C API and
command line interface) are identified and authenticated.
2. Authentication Policy for Resource Manager administrators and Resource Users
The authentication process of the underlying operating system for these users is ex-
tended by applying a TOE authentication policy.
Note that the verification of the user's authentication secrets is not part of the authentica-
tion policy's application.
3. Assigning credentials to authenticated administrators
The credentials of authenticated administrator are eventually created from the informa-
tion stored in the user registry within the LDAP server.
4. Assigning credentials to authenticated users
The credentials of authenticated users are eventually created from the information stored
in the user registry within the LDAP server. If no user record is defined in the user regis-
try, the user is treated as unauthenticated.
5. Access Control to protected objects of the underlying system
Those objects are protected as defined in the policy defined by an administrator on the
Policy Manager.
6. Access Control to TOE management objects
A flexible management model can limit the administration capabilities of administrative
users to defined sections of the protected object space.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 22 2006-02-01
7. Auditing of activities
The TOE is capable of auditing defined events.
8. Secure Communication
The TOE employs secure communication channels to communicate between its entities.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 23 2006-02-01
3 TOE Security Environment
3.1 Assumptions
The description of assumptions describes the security aspects of the environment in which
the TOE will be used or is intended to be used. This includes the following:
• information about the intended usage of the TOE, including such aspects as the in-
tended application, potential asset value, and possible limitations of use; and
• information about the environment of use of the TOE, including physical, personnel, and
connectivity aspects.
A.ADMIN The system administrative personnel are not careless, willfully
negligent, or hostile, and will follow and abide by the instructions
provided by the administrator guidance. Base administrators will
perform administration activities from a secure environment us-
ing terminals and/or workstations they trust via secured connec-
tions to the Policy Server. All administrative commands them-
selves will be executed on the Policy Server or on a TAMOS
RM.
A.BOOT During operating system startup it is ensured that the TAMOS
RM is started before user logins can occur.
A.DIR_PROT The directory server used by the TOE provides protection
mechanisms against unauthorized access to TSF data stored in
the directory. This includes the assumptions that queries are
properly authenticated, that replicas are held consistent accord-
ing to a well-defined policy, and that communication between
TOE and LDAP server is SSL v3 encrypted. .
A.FRIENDLY_OS The underlying operating system of a resource manager works
as specified. In particular, the operating system kernel is as-
sumed to be well behaved with regard to the TSF parts operat-
ing in kernel mode. It does not alter, hinder or otherwise influ-
ence the kernel mode operation of the TOE, it rather supports
them.
A.OS_CONF_MGMT The operating systems of the machines running the TOE are
assumed to be configured and maintained by trained and trust-
worthy personnel such that the underlying systems provide a
reliable basis for the operation of the TOE software.
A.PAM The authentication mechanisms in the underlying operating sys-
tem for the TAMOS RM effectively identify the operating system
users and associate them with correct user IDs. Furthermore,
the PAM mechanism (or loadable authentication module
mechanism on AIX) enforces the invocation of the TOE’s login
module, if so configured.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 24 2006-02-01
A.PHYS_PROT The machines running the TOE software need to be protected
against unauthorized physical access and modification. All ma-
chines running parts of the TOE software require this protection.
A.PWD_SAFE Administrators and other users have to protect their passwords
used for authentication to the TOE such that no unauthorized
access to them is possible.
A.USER Users of the TOE are not hostile and do not try to deliberately
attack the TSF. Especially, they do not possess greater attack
potential as assumed in the description of the threat environ-
ment for the TOE.
A.USER_PASSWORD The underlying operating system for a resource manager en-
sures that users are authenticated.
A.FRIENDLY_LDAP The LDAP server performs its functions as specified.
3.2 Threats
This section identifies the security threats originating from the TOE environment. The TOE
counters the general threat of unauthorized access to information, where “access” includes
disclosure, modification and destruction.
The assets to be protected are comprised of the information stored, processed or transmit-
ted by the TOE, and the information that the TOE mediates access to. The term “informa-
tion” is used here to refer to all data used by the TOE to enforce the TOE security policies,
regardless of the location of such data, and to information in the TOE environment that the
TOE mediates access to.
The assets to be protected are therefore:
• TSF data, especially
o The Authorization Policy database (including replicas and caches of this data-
base) which stores the data upon which access decisions are taken.
o The user registry hosted on an LDAP server in the IT environment, which con-
tains the user and group definitions utilized by the TOE.
• User data of the managed resources
o The TOE is not directly and solely responsible for the protection of data stored on
managed resources, but it contributes to their protection by making and enforcing
decisions on access to those resources, making them assets in terms of the
TSP.
The threat agents can be categorized as:
• Authorized users of the managed resource
Those are authorized users of the TOE and the underlying operating system, i.e. indi-
viduals who have successfully authenticated themselves against the underlying operat-
ing system and are authorized to access resources in the underlying operating system
as mediated by the TOE’s access control policy. Note that those users do not necessar-
ily need to be known to the TOE, in which case the TOE will treat them as “unauthenti-
cated” with respect to the defined access control policies – this still requires that they
have been authenticated successfully by the underlying operating system.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 25 2006-02-01
• Authorized administrators of the TOE
These individuals have successfully authenticated themselves to the TOE and may per-
form administrative tasks via the pdadmin interface within their administrative responsi-
bilities. A special case are TAMOS RM Administrators, which have been authenticated
by the underlying operating system of a resource manager and are granted special privi-
leges to use the management functions of the TOE on the managed resource.
• Network-based attackers
This class of threat agents does not possess any accounts on the managed resource or
the TOE itself, but has access to the network or parts of the network that connects policy
server, resource managers, and/or LDAP repositories.
The threat agents are assumed to originate from a well managed user community in a non-
hostile working environment, and hence the TOE protects against threats of inadvertent or
casual attempts to breach the system security. The TOE is not intended to be applicable to
circumstances in which protection is required against determined attempts by hostile and
well funded attackers to breach system security. An example of an environment meeting the
intended assurance level of this evaluation is a company, providing operating system ac-
cess to employees, well protected from external attacks and with an overall user community
that can be assumed to be non-hostile.
System administrators of the TOE as well as those for the underlying operating system and
the LDAP repository in the IT environment are assumed to be trustworthy and follow the in-
structions provided to them with respect to the secure configuration and operation of the
systems under their responsibility. Also, assumptions on the protection of the policy server
are made. (See section 3.1.)
The threats listed below are grouped according to whether or not they are countered by the
TOE. Those that are not countered by the TOE are to be countered by environmental or ex-
ternal mechanisms.
3.2.1 Threats to be countered by the TOE
T.BYPASS An authorized user of a managed resource or network-based
attacker accesses resources protected by the TOE in a way that
bypasses the TSF, exploiting non-TSF portions of the TOE.
T.COM_ATT An attacker intercepts the communication between the TOE and
an external entity or between distributed parts of the TOE in or-
der to get access to protected information, to impersonate as an
authorized user or part of the TOE or to manipulate the data
transmitted between the TOE and an external or internal entity.
T.UAACTION An undetected violation of the TSP may be caused as a result of
an authorized user of a managed resource or network-based
attacker attempting to perform actions that they are not author-
ized to do.
T.UAUSER An authorized user of a managed resource or a network-based
attacker may impersonate an authorized user of the TOE. This
includes the threat of an authorized user that tries to imperson-
ate as another authorized user without knowing the authentica-
tion credentials.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 26 2006-02-01
3.2.2 Threat to be countered by the TOE environment
TE.BYPASS An authorized user of a managed resource or network-based
attacker accesses resources protected by the TOE in a way that
bypasses the TSF due to the absence of protection mecha-
nisms in the underlying system.
3.3 Organizational Security Policies
The following organizational security policies are deemed appropriate in a security environ-
ment for the TOE:
P.ACCOUNTABILITY The administrators of the system shall be held accountable for
their actions within the system.
P.ADM_DELEGATION Specific administration tasks as well as management operations
to defined subsets of the resources protected by the TOE may
be delegated to administrators that are only allowed to perform
the management tasks within their defined area of responsibility
and are not able to extend this area themselves.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 27 2006-02-01
4 Security Objectives
This section defines the security objectives of the TSF and its supporting environment. Se-
curity objectives are categorized as IT security objectives for the TOE or the IT environment
as well as non-IT security objectives to be met by organizational means in the TOE envi-
ronment.
4.1 Security Objectives for the TOE
O.ACC_ADM The TSF must control the definition and management of access
control rules, policies and other security function properties and
restrict those activities to authorized administrators. The TSF
must allow restricting the rights of some administrators to define
access control rules for a subset of the protected object space
only.
O.AUDITING The TSF must record the security relevant actions of users and
administrators of the TOE. The TSF must present this informa-
tion to authorized administrators.
O.AUTHENT_ADMIN The TSF must enforce the authentication of Base administrators
which request access to the TOE and its resources.
Note: The authentication decision is derived from an external
LDAP server.
O.AUTHORIZATION The TSF must ensure that only authorized administrators and
users gain access to the TOE and the resources it protects.
Note: The access control rules may also allow unauthenticated
users, i.e. such users that are not known to the TOE, to access
resources explicitly defined to be accessible to unauthenticated
users.
O.SEC_COM Communication between physically distributed parts of the TOE
must be secured to ensure the integrity and confidentiality of the
communication.
O.SOF The TSF must enforce a password policy for the TOE’s adminis-
trators and users that protects against attacks of attackers with
moderate attack potential.
4.2 IT Security Objectives for the Environment
4.2.1 IT Security Objectives for the underlying operating system
OE.OS_AUTH The underlying system of a resource manager must reliably au-
thenticate users.
OE.OS_CFG_PROT The underlying operating systems for Policy Server and re-
source manager must provide protection for files comprising the
TOE and for shared memory containing TSF or user data a-
gainst unauthorized access.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 28 2006-02-01
OE.OS_TIME The underlying operating systems within IT environment must
provide a reliable time source.
OE.SEPARATION The underlying system for a resource manager must provide
proper separation mechanisms protecting the TOE and itself
from interference and tampering by untrusted subjects.
4.2.2 IT Security Objectives for the LDAP server
OE.DS_ACCESS_CTRL The LDAP server must provide authentication and access con-
trol mechanisms to prohibit unauthorized access to directory
entries containing TSF data. This access control must be en-
forced when importing and exporting data.
OE.FRIENDLY_DS The LDAP server must perform according to its specification, in
particular the bind and attribute compare functions and the rep-
lication mechanisms.
4.3 Non-IT Security Objectives for the Environment
OE.CREDEN Those responsible for the TOE must ensure that all access cre-
dentials, such as passwords or other authentication information,
are protected by the users in a manner which maintains IT secu-
rity objectives. The TOE environment must ensure that authen-
tication data of TAMOS RM users, i.e. users logging in to man-
aged resources, are adequately protected against disclosure
when in transit.
OE.INSTALL Those responsible for the TOE must ensure that the TOE is de-
livered, installed, managed, and operated in a manner which
maintains IT security objectives.
OE.OS_OPERATE The operating systems of the machines running the TOE must
be configured and maintained such that the underlying systems
provide a reliable basis for the operation of the TOE software.
The operating systems are configured such that no unauthor-
ized access to functions provided by the operating system soft-
ware (including network daemons) is possible either locally or
via any network connection.
OE.PHYSICAL Those responsible for the TOE must ensure that those parts of
the TOE critical to security policy are protected from physical
attack that might compromise IT security objectives.
OE.REPLICAS In case LDAP replicas are used in the IT environment, those
responsible for the TOE must ensure that the LDAP replication
mechanism – in particular with respect to the availability of con-
sistent TSF data across all replicas – conforms with a well-
defined policy
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 29 2006-02-01
OE.SEC_INTEGRATE Those responsible for the TOE must ensure that the TOE is in-
tegrated into the overall system in a way that prohibits direct
access to resources to be protected by the TOE in a way that
bypasses the TOE and its security functions.
This includes that the communication between remote compo-
nents of the TOE and supporting infrastructure in the IT envi-
ronment (i.e. with the LDAP repository) is protected against un-
authorized interception, either by organizational/physical means
(for example, a dedicated network) or by logical means (for ex-
ample, SSL/TLS).
This includes further that those responsible for the TOE shall
seek assurance that the underlying system of a resource man-
ager works as specified.
OE.USER Those responsible for the TOE shall control the user community
that can request access to resources protected by the TOE.
This includes a configuration where the client systems allowed
to submit requests to the TOE are controlled (for example, a
company internal network with a known and controlled user
community protected against unauthorized access from external
networks).
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 30 2006-02-01
5 IT Security Requirements
This chapter defines the security requirements for the TOE as well as the TOE environment.
Chapter 5.1 defines the security requirements for the TOE itself, separated into security
functional requirements and security assurance requirements. Those requirements use the
appropriate Common Criteria functional and assurance components with all the required
operations performed. Operations are marked in bold and italics. In addition some refine-
ments of SFRs as defined in the Common Criteria had to be made. Those are marked in
bold, italics and underlined. Iterations are marked by appending an additional identifier to
the SFR reference.
Chapter 5.2 defines the security requirements for the IT environment, separate for each
component within the environment. Here only security functional requirements are defined
using the Common Criteria functional components where appropriate. Not all operations
have been performed for those components to allow for the necessary flexibility in the selec-
tion of the products used in the environment. The security functional requirements defined in
this section try to identify a minimum set of requirements needed to get a secure Tivoli Ac-
cess Manager Environment.
Chapter 5.3 then defines the security requirements for the non-IT environment. They are
expressed without using the Common Criteria functional components because they are not
suitable to describe non-technical security requirements
Note that in the definition of the SFRs the terms (a) “users” and (b) “administrators” are
used to distinguish between (a) all users of the managed resource, including TAMOS RM
administrators and (b) Base administrators only, if not noted otherwise. This reflects the ac-
tual technical view based on which the roles known to the TOE are implemented.
5.1 Extended Components Definition
5.1.1 FAU_GEN.3-TAMOS
Rationale: This explicitly statement requirement is introduced to reflect the audit capabilities
of the TAMOS RM which could not be expressed using functional requirements from CC
part 2. Since this explicitly stated requirement is derived from FAU_GEN.1, the assurance
requirements applicable to FAU_GEN.1 apply FAU_GEN.3-TAMOS as well.
Component leveling: FAU_GEN.3-TAMOS is not hierarchical to FAU_GEN.1 or
FAU_GEN.2.
Management: FAU_GEN.3-TAMOS – No management activities are foreseen.
Audit: No actions are identified.
FAU_GEN.3-TAMOS Audit data generation
FAU_GEN.3-TAMOS.1 The TSF shall be able to generate an audit record of the following au-
ditable events:
a) All auditable events for the [selection: choose one of: minimum, basic,
detailed, not specified] level of audit; and
b) [assignment: other specifically defined auditable events]
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 31 2006-02-01
FAU_GEN.3-TAMOS.2 The TSF shall record within each audit record at least the following in-
formation:
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 PP/ST [assignment: other
audit relevant information]
Dependencies: FPT_STM.1
5.2 TOE Security Requirements
5.2.1 TOE Security Functional Requirements
FAU_GEN.1 Audit data generation
FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following audit-
able events:
a) Start-up and shutdown of the audit functions;
b) All auditable events for the not specified level of audit; and
c) The following defined events:
a. Policy Server:
• creation of user by administrator
• user locked by administrator
• user unlocked by administrator
• all commands of administrators that result in a
modification of the policy database
• locking of User ID (after three consecutive un-
successful authentication attempts)
FAU_GEN.1.2 The TSF shall record within each audit record at least the following infor-
mation:
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 PP/ST for Base admini-
stration commands: parameters passed to the command.
Application note: The “not specified level of audit” refers to the fact that no other audit records than
the ones specified here are subject to evaluation.
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.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 32 2006-02-01
FAU_GEN.3-TAMOS Audit data generation
FAU_GEN.3-TAMOS.1 The TSF shall be able to generate an audit record of the following au-
ditable events:
a) All auditable events for the not specified level of audit; and
b) The following defined events:
a. TAMOS RM:
• successful and unsuccessful authentication at-
tempts with a userid / password combination
• failed authorization for access to a protected re-
source
• locking of User ID (after three unsuccessful au-
thentication attempts within a defined time inter-
val)
• unlocking of User ID
• refresh of a user's credentials
FAU_GEN.3-TAMOS.2 The TSF shall record within each audit record at least the following in-
formation:
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 PP/ST not specified.
Application note: The “not specified level of audit” refers to the fact that no other audit records than
the ones specified here are subject to evaluation.
FAU_SAR.1(1) Audit review (Policy Server)
FAU_SAR.1.1 The TSF shall provide authorized administrators with the capability to
read all 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.
Application Note: The TOE does not provide a direct interface to read the audit trail. Instead the
administrator has to use a tool outside of the TOE to read the audit records. The
information in the audit files is human readable even when read with a program
like an editor.
FAU_SAR.1(2) Audit review (TAMOS RM)
FAU_SAR.1.1 The TSF shall provide authorized users with the capability to read all in-
formation 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.
Application Note: Audit records are stored in a binary log file format and tools are provided to ex-
tract human-readable information from the log files.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 33 2006-02-01
FAU_SEL.1(1) Selective audit (Policy Server)
FAU_SEL.1.1 The TSF shall be able to include or exclude auditable events from the set
of audited events based on the following attributes:
a) object identity, host identity
b) audit event category (authn, azn, mgmt)
Application Note: The audit categories can be defined on a per-server basis, which satisfies the se-
lection of “host identity” in a). POP can be used to define auditing on a per object
basis.
FAU_SEL.1(2) Selective audit (TAMOS RM)
FAU_SEL.1.1 The TSF shall be able to include or exclude auditable events from the set
of audited events based on the following attributes:
a) object identity, subject identity
b) event outcome (for objects: permit, deny, all, none; for users:
permit, deny, loginpermit, logindeny, all, none)
FAU_STG.1 Protected audit trail storage
FAU_STG.1.1 The TSF shall protect the stored audit records from unauthorized dele-
tion.
FAU_STG.1.2 The TSF shall be able to prevent modifications to the audit records.
Application Note: The protection from unauthorized deletion is achieved with the TOE setting the
access permissions to the audit files appropriately. Prevention of modifications
also is based on the access rights to the audit files and by the fact that the TOE
itself does not provide any function that could be used to modify the audit records
once stored in the audit file. This security functional requirement of course also
relies on the appropriate protection of the TOE itself against unauthorized access
in the TOE environment.
FCS_CKM.1(1) Cryptographic key generation (Symmetric algorithms)
FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a speci-
fied cryptographic key generation algorithm as defined in the SSL v3
standard and specified cryptographic key sizes 128 bit (RC4), 168 bit
(TDES) that meet the following: generation and exchange of session
keys as defined in the SSL v3 standard with the cipher suites de-
fined in FCS_COP.1(2).
Application Note: Generation of symmetric keys is defined in section 6.2 in the SSL v3 standard.
FCS_CKM.1(2) Cryptographic key generation (RSA)
FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a speci-
fied cryptographic key generation algorithm product specific and speci-
fied cryptographic key sizes 1024 bit that meet the following: not speci-
fied
Application Note: The SSL v3 specification does not define how the RSA key pair is generated.
This is up to the implementation. Almost all implementations of the SSL v3 stan-
dard have their own algorithm for RSA key pair generation (if they support cipher
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 34 2006-02-01
suites that use RSA). Therefore the key generation and algorithm and the stan-
dard to follow are not defined here. Only the required key size is specified.
FCS_CKM.2(1) Cryptographic key distribution (RSA public keys)
FCS_CKM.2.1 The TSF shall distribute cryptographic keys in accordance with a speci-
fied cryptographic key distribution method digital certificates that meets
the following: certificate format as defined in X.509 Version 3.
Application Note: This requirement addresses the exchange of public RSA keys as part of the SSL
client and server authentication. For a definition of the certificate format see
[X.509].
FCS_CKM.2(2) Cryptographic key distribution (Symmetric keys)
FCS_CKM.2.1 The TSF shall distribute cryptographic keys in accordance with a speci-
fied cryptographic key distribution method Secure Socket Layer hand-
shake using RSA encrypted exchange of session keys that meets the
following: SSL Version 3 (Internet Draft dated November 1996, Net-
scape Communication).
Application Note: This requirement addresses the exchange of SSL session keys as part of the
SSL handshake protocol.
FCS_COP.1(1) Cryptographic operation (RSA)
FCS_COP.1.1 The TSF shall perform digital signature generation and digital signa-
ture verification in accordance with a specified cryptographic algorithm
RSA and cryptographic key sizes 1024 bit that meet the following: SSL
Version 3 (Internet Draft dated November 1996, Netscape Communi-
cation).
Application Note: This requirement addresses the RSA digital signature generation and verification
operations using the RSA algorithm as required by the SSL session establish-
ment protocol (provided a cipher suite including RSA is used). Note that the de-
tails of the signature format like the use of the PKCS#1 block type 1 and block
type 2 are defined in the SSL Version 3 standard.
FCS_COP.1(2) Cryptographic operation (Symmetric operations)
FCS_COP.1.1 The TSF shall perform encryption and decryption in accordance with a
specified cryptographic algorithm RC4 and TDES and cryptographic key
sizes 128 bit (RC4) or 168 bit (TDES) that meet the following: SSL Ver-
sion 3 (Internet Draft dated November 1996, Netscape Communica-
tion) and the following cipher suites:
SSL_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_MD5,
SSL_RSA_WITH_3DES_EDE_CBC_SHA as defined in the SSL v3
standard.
Application Note: GSKit supports also other cipher suites that use RSA based key exchange listed
in the SSLv3 standard. The cipher suites listed above are the ones supported in
the evaluated configuration.
FDP_ACC.2(1) Complete access control
FDP_ACC.2.1 The TSF shall enforce the Object-Space access control policy on us-
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 35 2006-02-01
ers as subjects and objects in the TAMOS RM protected object
space 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.
FDP_ACC.2(2) Complete access control
FDP_ACC.2.1 The TSF shall enforce the management access control policy on ad-
ministrators as subjects and objects in the management protected
object space 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.
FDP_ACF.1(1) Security attribute based access control
FDP_ACF.1.1 The TSF shall enforce the security attribute based Object-Space ac-
cess control policy to objects based on the following:
Users as subjects and objects in the TAMOS RM protected object
space controlled by access control lists (ACL), protected object
policies (POP) and Access Restriction Extended Attributes Policy
(AREAP).
FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an operation
among controlled subjects and controlled objects is allowed:
Users have the requested type of access to a protected object in the
Object-Space under the following conditions:
1. the user has been successfully authenticated and identified and
the user has the “traverse” right for all objects from the root ob-
ject down the path to the requested object and
• the user has an entry in the ACL associated with the ob-
ject that contains the requested type of access, or
• the user is member of a group that has an entry in the
ACL associated with the object that contains the re-
quested type of access, or
• the ACL associated with the object has an entry of type
“any-other” that contains the requested type of access
2. the user has been successfully authenticated but unsuccessfully
identified and a traverse right exists for all objects from the root
object down the path to the requested object for unauthenticated
users and
• the ACL associated with the object has both an entry of type
“any-other” and an entry of type “unauthenticated” where the
requested access right is contained in both entries
The “ACL associated with the object” is the ACL of the object if the
object has an explicit ACL or the ACL inherited from the next object
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 36 2006-02-01
up on the path to the root that has an explicit ACL.
FDP_ACF.1.3 The TSF shall explicitly authorize access of subjects to objects based on
the following additional rules: none
FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the
1. rules defined by the Protected Object Policy, if such a Protected
Object Policy has been defined for the requested object. Pro-
tected Object Policies can deny access based on
• the time-of-day
2. rules defined by the Access Restriction Extended Attributes Pol-
icy, if such an Access Restriction Extended Attributes Policy
has been defined for the requested object. Access Restriction
Extended Attributes Policy can deny access based on
• the accessor
• the permission set
• the program used
FDP_ACF.1(2) Security attribute based access control
FDP_ACF.1.1 The TSF shall enforce the security attribute based management access
control policy to objects based on the following:
Administrators as subjects and objects in the management pro-
tected objects space controlled by access control lists (ACL) and
protected object policies (POP).
FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an operation
among controlled subjects and controlled objects is allowed:
Users have the requested type of access to a protected object in the
Object-Space under the following conditions:
1. the user has been successfully authenticated and
• the user has the “traverse” right for all objects from the root
object down the path to the requested object and
• the user has an entry in the ACL associated with the object
that contains the requested type of access, or
• the user is member of a group that has an entry in the ACL
associated with the object that contains the requested type of
access, or
• the ACL associated with the object has an entry of type “any-
other” that contains the requested type of access
2. the user has not been authenticated and
• a traverse right exist for all objects from the root object down
the path to the requested object for unauthenticated users
and
• the ACL associated with the object has both an entry of type
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 37 2006-02-01
“any-other” and an entry of type “unauthenticated” where the
requested access right is contained in both entries
The “ACL associated with the object” is the ACL of the object if the
object has an explicit ACL or the ACL inherited from the next object
up on the path to the root that has an explicit ACL.
FDP_ACF.1.3 The TSF shall explicitly authorize access of subjects to objects based on
the following additional rules: none
FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the
Rules defined by the Protected Object Policy, if a Protected Object
Policy has been defined for the requested object. Protected Object
Policies can deny access based on
• the time-of-day
FIA_AFL.1(1) Authentication failure handling (Policy Server)
FIA_AFL.1.1 The TSF shall detect when three unsuccessful authentication attempts
occur related to password based authentication attempts of adminis-
trators.
FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has
been met or surpassed, the TSF shall disable further login attempts of
that user for a time interval of not less than 180 seconds as defined
by the administrator in the disable-time-interval configuration pa-
rameter.
FIA_AFL.1(2) Authentication failure handling (TAMOS RM)
FIA_AFL.1.1 The TSF shall detect when three unsuccessful authentication attempts
occur related to password based authentication attempts of users.
FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has
been met or surpassed, the TSF shall disable further login attempts of
that user for a time interval of not less than 180 seconds as defined
by the administrator in the Login-LockMinutes configuration pa-
rameter in the /OSSEAL/policy-branch/Login policy space.
FIA_ATD.1(1) User attribute definition
FIA_ATD.1.2 The TSF shall maintain the following list of security attributes belonging to
individual users: user identifier, registry identifier (distinguished
name), list of groups the user belongs to.
Application Note: The user’s common name and surname are not security attributes. The user at-
tributes are stored in an external LDAP server.
FIA_ATD.1(2) Administrator attribute definition
FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to
individual administrators: user name, registry identifier (distinguished
name), password, list of groups the user belongs to.
Application Note: The term “user” in the CC SFR FIA_ATD.1 has been refined by “administrator” to
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 38 2006-02-01
differentiate the attribute definition of users and administrators. The administra-
tor’s common name and surname are not seen as security attributes. The admin-
istrator attributes are stored in an external LDAP server.
FIA_SOS.1 Verification of secrets
FIA_SOS.1.1 The TSF shall provide a mechanism to verify that secrets meet the fol-
lowing conditions:
1. Minimum password length is 8 characters
2. Minimum number of alphabetic characters is 4
3. Minimum number of non-alphabetic character is 1
4. Maximum number of repeated characters is 2
Application Note: Those parameters are configurable by the administrator.
Application Note: This requirement is valid for both the Policy Server and TAMOS RM enforced au-
thentication policy.
FIA_UAU.2 Administrator authentication before any action (Policy Server)
FIA_UAU.2.1 The TSF shall require each administrator to be successfully authenti-
cated before allowing any other TSF-mediated actions on behalf of that
administrator.
Application Note: The term “user” in the CC SFR FIA_UAU.2 has been refined by “administrator” to
differentiate the authentication policy of users and administrators. While there is
a possibility of unauthenticated users, all administrators (which use a different in-
terface for authentication) are required to authenticate successfully before per-
forming any administrative action on the TOE.
FIA_UID.1 Timing of identification
FIA_UID.1.1 The TSF shall allow access as defined in the bitwise ‘and’ of the ‘any-
other’ and ‘unauthenticated’ entry in an object’s ACL 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 al-
lowing any other TSF-mediated actions on behalf of that user.
Application Note: An ACL may contain an entry that defines the access modes allowed for anony-
mous users, i.e. users that are not identified and authenticated.
FIA_UID.2 Administrator identification before any action (Policy Server)
FIA_UID.2.1 The TSF shall require each administrator to identify itself before allowing
any other TSF mediated actions on behalf of that administrator.
Application Note: The term “user” in the CC SFR FIA_UID.2 has been refined by “administrator” to
differentiate the authentication policy of users and administrators. While there is
a possibility of unauthenticated users, all administrators (which use a different in-
terface for authentication) are required to authenticate successfully before per-
forming any administrative action on the TOE.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 39 2006-02-01
FIA_USB.1 User-subject binding
FIA_USB.1.1 The TSF shall associate the following user security attributes with sub-
jects acting on behalf of that user:
1. the user identity associated with auditable events;
2. the user and group identities used to enforce the security attrib-
ute based Object-Space access control policy and the manage-
ment access control policy.
Application Note: The TSS specifies the security attributes that are of relevance for the TSF and
how they are associated with users.
FMT_MOF.1 Management of security functions behavior
FMT_MOF.1.1 The TSF shall restrict the ability to modify the behavior of the functions
authentication, audit, and authorization to authorized administrators.
FMT_MSA.1 (1) Management of security attributes
FMT_MSA.1.1 The TSF shall enforce the management access control policy to re-
strict the ability to modify or delete the security attributes ACL entries to
users or groups having ‘control’ access for the ACL.
FMT_MSA.1 (2) Management of security attributes
FMT_MSA.1.1 The TSF shall enforce the management access control policy to re-
strict the ability to change_default, modify or delete the security attrib-
utes ACL, POP and Access Restriction Extended Attributes to au-
thorized administrators.
FMT_MSA.2 Secure security attributes
FMT_MSA.2.1 The TSF shall ensure that only secure values are accepted for security
attributes.
FMT_MSA.3 Static attribute initialization
FMT_MSA.3.1 The TSF shall enforce the management access control policy and Ob-
ject-Space access control policy to provide inherited default values for
security attributes that are used to enforce the SFP.
FMT_MSA.3.2 The TSF shall allow the administrator authorized to modify the ACL of
the container object to specify alternative initial values to override the
default values when an object or information is created.
Application Note: If no ACL is attached to an object, this object inherits the ACL attached to con-
tainer object that contains the object. This inheritance rule goes ‘upward’ in the
protect object space tree until a container object with an ACL is reached. This
rule is expressed with this requirement.
FMT_MTD.1 Management of TSF data
FMT_MTD.1.1 The TSF shall restrict the ability to modify and delete the user attribute
data to authorized administrators.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 40 2006-02-01
FMT_SMF.1 Specification of Management Functions
FMT_SMF.1.1 The TSF shall be capable of performing the following security manage-
ment functions:
1. User and group management
2. ACL, POP and Access Restriction Extended Attributes manage-
ment
3. Audit management
4. TOE certificate management
5. Login policy management
6. Password management
Application Note: Management of attributes for 1), 4), 5) and 6) makes use of an external LDAP
server.
FMT_SMR.1 Security roles
FMT_SMR.1.1 The TSF shall maintain the roles users and administrators.
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
Application Note: Administration tasks can be delegated by the initially defined administrator (sec-
master) to other administrators that he has created. The tasks a specific adminis-
trator is allowed to perform can be defined on a fine-grained basis as described
in chapter 6. The term ‘administrator’ is used in this Security Target for any ad-
ministrator that has been defined to perform administrative actions via the pdad-
min interface.
FPT_ITT.1 Basic internal TSF data transfer protection
FPT_ITT.1.1 The TSF shall protect TSF data from disclosure and modification when
it is transmitted between separate parts of the TOE.
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.
FPT_TRC.1 Internal TSF consistency
FPT_TRC.1.1 The TSF shall ensure that TSF data is consistent when replicated be-
tween parts of the TOE.
FPT_TRC.1.2 When parts of the TOE containing replicated TSF data are disconnected,
the TSF shall ensure the consistency of the replicated TSF data upon re-
connection before processing any requests for access permission.
Application Note: The documentation describes the process where a notification can be sent out by
the policy server to all authorization servers with replica of the master database.
It is not described how the policy server checks that the authorization servers
have received this notification (e. g. if they are not reachable at the time the noti-
fication has been sent out). As an alternative authorization servers can check for
database updates by polling the policy server.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 41 2006-02-01
FTP_ITC.1 Inter-TSF trusted channel
FTP_ITC.1.1 The TSF shall provide a communication channel between itself and a re-
mote trusted IT product that is logically distinct from other communication
channels and provides assured identification of its end points and protec-
tion of the channel data from modification or disclosure.
FTP_ITC.1.2 The TSF shall permit the TSF to initiate communication via the trusted
channel.
FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for the
communication with the LDAP server .
Application Note: The trusted channel is established using the SSL v3 protocol with client authenti-
cation. In the case of the LDAP server the TOE acts as a client (as seen by the
SSL protocol). The SSL v3 protocols define the client as the communication
partner that initiates the communication over the trusted channel.
5.2.2 TOE Security Assurance Requirements
The target evaluation assurance level for the product is EAL3 [CC] augmented by
ALC_FLR.1.
5.3 Security Requirements for the IT Environment
There are several components used in the IT environment of the TOE that need to satisfy a
number of security requirements to ensure a secure operation of the TOE in its environ-
ment. Those security functional requirements are defined in this section, separate for each
system within the TOE environment. The functional components of the Common Criteria
(part 2) have been taken to describe those security functional requirements and the opera-
tions within those components have been performed whenever possible and useful. It
should be noted that the security functional requirements defined here are a minimum set
that need to be satisfied by those components to ensure the secure operation of Tivoli Ac-
cess Manager within its intended environment. In most cases the components will have
more security functions than defined here, allowing for a more flexible type of operation or
even providing a higher level of security.
It should be noted that the security requirements for the components in the IT environment
are not intended to be complete specifications of all security requirements of such a compo-
nent. Only those requirements required by the TOE are defined.
5.3.1 LDAP Server
Summary and Justification
The TOE uses an external LDAP Server to store and maintain data related to the users and
administrators of the TOE. The LDAP Server is required to protect this data against unau-
thorized access and disclosure. This requires functions for identification and authentication
as well as access control for those directory entries belonging to the TOE. The TOE also
uses the LDAP server to determine authentication decisions for Base administrators based
on the user registry information stored in the server.
It is not required to have an LDAP Server dedicated to one specific instantiation of Tivoli Ac-
cess Manager for Operating Systems. But it is required that the subset of the directory “be-
longing” to a specific instantiation of Tivoli Access Manager for Operating Systems is pro-
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 42 2006-02-01
tected against unauthorized access of any kind by anybody other than a server belonging to
the specific instantiation of Tivoli Access Manager. If one directory server is used for several
instantiations of Tivoli Access Manager or other applications, the separation or sharing of di-
rectory entries has to be defined by the organization (which also includes a clarification of
the question how to manage the directory in the case of shared directory entries).
The following section defines the minimum security functional requirements for the Directory
Server using Common Criteria functional requirements components. Not all operations on
the components have been performed. Some of them can not be performed without placing
unnecessary restrictions on the Directory Server.
FDP_ACC.1 Subset access control
FDP_ACC.1.1 The IT environment shall enforce the Directory Access Control Policy
on servers belonging to a TOE instantiation as subject, directory en-
tries belonging to the TOE instantiation as objects and all opera-
tions that create, read, modify or delete those objects.
FDP_ACF.1 Security attribute based access control
FDP_ACF.1.1 The IT environment shall enforce the Directory Access Control Policy
to objects based on successful authentication of a server that is part
of the TOE instantiation.
FDP_ACF.1.2 The IT environment shall enforce the following rules to determine if an
operation among controlled subjects and controlled objects is allowed: If
the server is successfully authenticated to belong to the TOE instan-
tiation all access to directory records belonging to this instantiation
of TOE is allowed.
FDP_ACF.1.3 The IT environment shall explicitly authorize access of subjects to ob-
jects based on the following additional rules: None.
FDP_ACF.1.4 The IT environment shall explicitly deny access of subjects to objects
based on the [assignment: rules, based on security attributes, that explic-
itly deny access of subjects to objects].
Application Note: The assignment in FDP_ACF.1.4 has not been performed, since it is up to the
local security policy of the Directory Server to define such additional restrictions.
The security of Tivoli Access Manager for Operating Systems does not rely on
such additional restriction but also does not demand that they should not exist.
FDP_ETC.1 Export of user data without security attributes
FDP_ETC.1.1 The IT environment shall enforce the Directory Access Control Policy
when exporting user data, controlled under the SFP(s), outside of the
TSC.
FDP_ETC.1.2 The IT environment shall export the user data without the user data’s
associated security attributes.
FDP_ITC.1 Import of user data without security attributes
FDP_ITC.1.1 The IT environment shall enforce the Directory Access Control Policy
when importing user data, controlled under the SFP, from outside of the
TSC.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 43 2006-02-01
FDP_ITC.1.2 The IT environment shall ignore any security attributes associated with
the user data when imported from outside the TSC.
FDP_ITC.1.3 The IT environment shall enforce the following rules when importing
user data controlled under the SFP from outside the TSC: [assignment:
additional importation control rules].
Application Note: The assignment in FDP_ITC.1.3 has not been performed, since it is up to the lo-
cal security policy of the Directory Server to define those rules. The security of
Tivoli Access Manager for Operating Systems does not rely on those rules.
FIA_UAU.2 User authentication before any action
FIA_UAU.2.1 The IT environment shall require each user to be successfully authenti-
cated before allowing any other TSF-mediated actions on behalf of that
user.
FIA_UID.2 User identification before any action
FIA_UID.2.1 The IT environment shall require each user to identify itself before allow-
ing any other TSF-mediated actions on behalf of that user.
FMT_MSA.1 Management of security attributes
FMT_MSA.1.1 The IT environment shall enforce the Directory Access Control Policy
to restrict the ability to [selection: change_default, query, modify, delete,
[assignment: other operations]] the security attributes [assignment: list of
security attributes] to [assignment: the authorized identified roles].
Application Note: The Directory Server shall enforce an access control policy on directory entries,
but the details of this policy including the rights of the individual roles have to be
defined in a Security Target for the Directory Server. This TOE does not define
specific requirements for the capability of this policy and the role model of the Di-
rectory Server.
FMT_MSA.3 Static attribute initialization
FMT_MSA.3.1 The IT environment shall enforce the Directory Access Control Policy
to provide [selection: restrictive, permissive, other property] default values
for security attributes that are used to enforce the SFP.
FMT_MSA.3.2 The IT environment shall allow the [assignment: the authorized identified
roles] to specify alternative initial values to override the default values
when an object or information is created.
FMT_SMF.1 Specification of Management Functions
FMT_SMF.1.1 The IT environment shall be capable of performing the following security
management functions: [assignment: list of security management func-
tions to be provided by the TSF].
FMT_SMR.1 Security roles
FMT_SMR.1.1 The IT environment shall maintain the roles [assignment: the authorized
identified roles].
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 44 2006-02-01
FMT_SMR.1.2 The IT environment shall be able to associate users with roles.
5.3.2 Underlying Operating System of the TOE components (Policy Server)
The underlying operating system for the Policy Server is required to provide a reliable time
stamp used for the generation of the date and time in the audit records generated by the
TOE. In addition the TOE makes use of a configuration file containing the types of audit
events that the TOE shall generate audit records for. This file needs to be edited by an OS
administrator and should be protected from unauthorized access and modifications by any
other user (if such a user is installed in the underlying OS). The TOE makes no use of any
other security function provided by the underlying operating system for the Policy Server.
FIA_UID.1 Timing of identification
FIA_UID.1.1 The IT environment shall allow [assignment: list of TSF-mediated ac-
tions] on behalf of the user to be performed before the user is identified.
FIA_UID.1.2 The IT environment shall require each user to be successfully identified
before allowing any other TSF mediated actions on behalf of that user.
FMT_MTD.1 Management of TSF data
FMT_MTD.1.1 The IT environment shall restrict the ability to modify the list of events to
be audited to OS administrators.
FMT_SMF.1 Specification of Management Functions
FMT_SMF.1.1 The IT environment shall be capable of performing the following security
management functions: [assignment: list of security management func-
tions to be provided by the TSF].
FMT_SMR.1 Security roles
FMT_SMR.1.1 The IT environment shall maintain the roles OS administrators and
[assignment: other authorized identified roles].
FMT_SMR.1.2 The IT environment shall be able to associate users with roles.
FPT_SEP.1 TSF domain separation
FPT_SEP.1.1 The IT environment shall maintain a security domain for the TOE’s exe-
cution that protects it from interference and tampering by untrusted sub-
jects.
FPT_SEP.1.2 The IT environment shall enforce separation between the security do-
mains of subjects in the TSC.
FPT_STM.1 Reliable time stamps
FPT_STM.1.1 The IT environment shall be able to provide reliable time stamps for the
TOE’s use.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 45 2006-02-01
5.3.3 Underlying Operating System of the TOE components (TAMOS RM)
The underlying operating system for the TAMOS RM is required to provide a reliable time
stamp used for the generation of the date and time in the audit records generated by the
TOE. In addition the TOE makes use of a configuration file containing the types of audit
events that the TOE shall generate audit records for. Domain separation is not only neces-
sary to enforce the underlying system’s security mechanisms, but also to support the TOE
by allowing it to operate within a protected security domain. Access control mechanisms in
the operating system, e.g. for shared memory and other IPC mechanisms, further support
the protection of TOE operations.
The underlying operating system plays a key role in the user authentication and identifica-
tion process. It must provide appropriate measures to fulfill these tasks.
FDP_ACC.1 Subset access control
FDP_ACC.1.1 The IT environment shall enforce the Operating System Policy on us-
ers of the operating system as subjects, file system and IPC objects,
and all transactions operating on these objects.
FDP_ACF.1 Security attribute based access control
FDP_ACF.1.1 The IT environment shall enforce the Operating System Policy to ob-
jects based on [assignment: security attributes, named groups of security
attributes].
FDP_ACF.1.2 The IT environment shall enforce the following rules to determine if an
operation among controlled subjects and controlled objects is allowed:
[assignment: rules governing access among controlled subjects and con-
trolled objects using controlled operations on controlled objects].
FDP_ACF.1.3 The IT environment shall explicitly authorize access of subjects to ob-
jects based on the following additional rules: [assignment: rules, based on
security attributes, that explicitly authorize access of subjects to objects].
FDP_ACF.1.4 The IT environment shall explicitly deny access of subjects to objects
based on the [assignment: rules, based on security attributes, that explic-
itly deny access of subjects to objects].
Application Note: The rules must allow the administrator of the underlying system to prevent any
unauthorized access to files containing TSF or user data belonging to the TOE.
FIA_ATD.1 User attribute definition
FIA_ATD.1.1 The IT environment shall maintain the following list of security attributes
belonging to individual users: [assignment: list of security attributes].
FIA_UAU.1 Timing of authentication
FIA_UAU.1.1 The IT environment shall allow [assignment: list of TSF mediated ac-
tions] on behalf of the user to be performed before the user is authenti-
cated.
FIA_UAU.1.2 The IT environment shall require each user to be successfully authenti-
cated before allowing any other TSF-mediated actions on behalf of that
user.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 46 2006-02-01
FIA_UID.1 Timing of identification
FIA_UID.1.1 The IT environment shall allow [assignment: list of TSF-mediated ac-
tions] on behalf of the user to be performed before the user is identified.
FIA_UID.1.2 The IT environment shall require each user to be successfully identified
before allowing any other TSF mediated actions on behalf of that user.
FIA_USB.1 User-subject binding
FIA_USB.1.1 The IT environment shall associate the appropriate user security attrib-
utes with subjects acting on behalf of that user.
FMT_MSA.1 Management of security attributes
FMT_MSA.1.1 The IT environment shall enforce the Operating System Policy to re-
strict the ability to [selection: change_default, query, modify, delete, [as-
signment: other operations]] the security attributes [assignment: list of se-
curity attributes] to [assignment: the authorized identified roles].
FMT_MSA.3 Static attribute initialization
FMT_MSA.3.1 The IT environment shall enforce the Operating System Policy to pro-
vide [selection: restrictive, permissive, other property] default values for
security attributes that are used to enforce the SFP.
FMT_MSA.3.2 The IT environment shall allow the [assignment: the authorized identified
roles] to specify alternative initial values to override the default values
when an object or information is created.
FMT_MTD.1 Management of TSF data
FMT_MTD.1.1 The IT environment shall restrict the ability to modify the list of events to
be audited to OS administrators.
FMT_SMF.1 Specification of Management Functions
FMT_SMF.1.1 The IT environment shall be capable of performing the following security
management functions: [assignment: list of security management func-
tions to be provided by the TSF].
FMT_SMR.1 Security roles
FMT_SMR.1.1 The IT environment shall maintain the roles OS administrators and
[assignment: other authorized identified roles].
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
FPT_SEP.1 TSF domain separation
FPT_SEP.1.1 The IT environment shall maintain a security domain for the TOE’s exe-
cution that protects it from interference and tampering by untrusted sub-
jects.
FPT_SEP.1.2 The IT environment shall enforce separation between the security do-
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 47 2006-02-01
mains of subjects in the TSC.
Application note: The underlying operating system provides a separation mechanism (kernel or
supervisor mode vs. user mode) to prevent unprivileged operations from interfer-
ing with the TOE security functions.
FPT_STM.1 Reliable time stamps
FPT_STM.1.1 The IT environment shall be able to provide reliable time stamps for the
TOE’s use.
5.4 Strength of Function (SOF) Claim
The overall SOF claim for this Security Target is SOF-medium. No specific metric is defined
and used for any permutational or probabilistic mechanisms.
A claim of SOF-medium is applied to the following security functional requirements:
• FIA_AFL.1(1)
• FIA_AFL.1(2)
• FIA_SOS.1
Please note that the cryptographic algorithms including the cryptographic hash algorithms
as well as the key generation process for the keys used in those algorithms are excluded
from the strength of function analysis in this evaluation.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 48 2006-02-01
6 TOE Summary Specification
6.1 Statement of TOE Security Functions
6.1.1 F.Audit
The TOE components can be individually configured with respect to the audit functions they
perform. This is done using a defined configuration mechanism, which defines the type of
events to be collected.
The TOE provides the capability to generate audit records for the following events:
1. TAMOS RM
a Authentication attempts (successful and unsuccessful).
b Authorization failures.
c Locking of User ID (after three unsuccessful authentication attempts within a defined
time interval).
d Unlocking of User ID.
e Refresh of User's credentials.
2. Policy Server (pdmgrd):
a New user created.
b User locked by administrator.
c User unlocked by administrator.
d Locking of User ID (after three consecutive unsuccessful authentication attempts).
e All administrator actions that result in modifications to the policy database.
Each audit event is recorded with the date and time, the identity of the user that caused the
event, the type of event and the success or failure. In the case of the Policy Server also all
parameters of commands issued by an administrator are audited together with the com-
mand.
The Policy Server and TAMOS RM provide functionality to roll over to a new audit file if the
current file exceeds an administrator-defined size.
6.1.1.1 Review of Audit Records
The pdosaudview command on the TAMOS RM is used to process a collection file gener-
ated by the TAMOS RM audit subsystem. The resulting output can be viewed, printed, or
analyzed by scripts and other programs. The following parameters can be used to select the
audit records in the produced output:
• Action
• Reason
• Outcome
• Accessor name
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 49 2006-02-01
• Accessor effective name
• Decision type of the aznAPI
• Originating process
• Resource type
• Start- and end-time
Policy Server audit records are written in XML-formatted audit trails that can be reviewed by
administrators. In addition, the Access Manager product provides an XML log viewer tool as
part of the TOE environment.
6.1.2 F.Authentication
The TOE is capable of authenticating Base administrators by making use of an external
LDAP server. Successful authentication is required before administrators can perform any
administrative action.
The user authentication process can be extended by applying login and password policies.
6.1.2.1 User Authentication Policies
“Users” are those entities that attempt to access resources via the operating system ser-
vices. In terms of authentication, this includes the TAMOS RM Administrators, but not Base
administrators.
User authentication is performed by the native operating systems in the IT environment. The
TOE can be configured to apply an additional login policy.
User Login Policy
The TOE supports policy that verifies a defined set of attributes against a policy's represen-
tation of these attributes stored in the user registry.
The TOE uses the user ID provided by the authentication process to decide which authenti-
cation policy to apply.
The TOE allows the following attributes to influence the authentication policy:
• A limit of successive failed login attempts. Note: This value is not maintained in the user
registry but locally on the Resource Manager instance that performs the authentication
process – there is no global counter for failed login attempts at multiple resource manag-
ers.
The required value for this attribute is 3.
• Time-of-day login restrictions define hours of the day and days of the week during which
users are permitted to log in. For users defined in the user registry, any user-specific pol-
icy overrides any global policy.
• Holiday login restrictions specify additional time-of-day restrictions by defining Holidays.
The ability of a user to log in on the holiday is controlled by the ACL attached to the same
resource.
• Login location restrictions specify where users can log in. Protected resources are de-
fined under the Terminal branch of the Login resource hierarchy to specify where users
can log in. Login locations are referred to as terminals.
• Login activity policy – the TOE provides the ability to define and enforce policy related to
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 50 2006-02-01
login activity. The TOE login activity policy is applied in addition to any such policy pro-
vided natively by the operating system. The more restrictive between the TAMOS RM
policy and the operating system policy will apply.
• User exception policy allows to define exceptions to the default login activity policy.
• Inactivity of user
The required value for this attribute is 256 days.
In addition, the TAMOS RM can apply a password management policy enforcing the follow-
ing properties:
• Password age
The required value for this attribute is 186 days.
• Password strength
Administrator defined parameters such as a minimum length for passwords.
The policies can be applied globally or on a per-user basis. The per-user policy takes
precedence over the global policy.
Refer to section 6.1.4.5 and 6.1.4.6 for a description of the management of the policies.
User-subject binding
To acquire the credentials needed to make an authorization decision, the accessing user’s
native numerical UNIX ID is mapped to a TAMOS RM user. The user’s UNIX username is
obtained from the system’s native user registry; this username is mapped one-to-one to a
TAMOS RM user of the same name to retrieve credentials from the user registry. These
credentials define the user’s identity and group membership. If there is no TAMOS RM user
corresponding to the user’s native username, then the user is treated as unauthenticated
when making authorization decisions. Users with disabled accounts are also treated as un-
authenticated.
The TOE associates the following user security attributes with subjects acting on behalf of
users:
1. The user identity which is associated with auditable events;
2. The user identity or identities which are used to enforce the Object-Space Policy;
3. The group membership or memberships used to enforce the Object-Space Policy;
Upon successful identification, the TAMOS RM user name is the one specified in the user
entry for the user that has authenticated successfully. If a user cannot be identified, the user
is considered an “unauthenticated user”.
The TOE restricts the use of the underlying operating system’s switch user/surrogate capa-
bilities. Users can change their effective user ID or group ID if they have permissions on the
Surrogate/User/username or Surrogate/Group/groupname objects or if they have permis-
sion on the .../Sudo/sudo-command object and use the pdossudo command. See also sec-
tions 6.1.3.5.3 and 6.1.3.5.4.
6.1.2.2 Authentication of Administrators
Base Administrators are authenticated with user ID and password and with use of an exter-
nal LDAP server. The TOE provides the pdadmin command line interface for administration
tasks. To execute a single administration command the administrator uses the following
pdadmin command structure:
pdadmin [-a admin_user] [-p password] command
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 51 2006-02-01
where admin_user is replaced by the administrator’s userid and password is replaced by the
password of the administrator. As an alternative the administrator can specify the command
without the password, the system will prompt the administrator for the correct password.
To execute a set of commands the administrator can create a file containing all the com-
mands and then issue the command
pdadmin [-a admin_user] [-p password] filename
where filename is replaced by the name of the file containing the set of commands the ad-
ministrator wants to be executed. As above he may omit the password from the command
line in which case he is prompted by the system for the correct password.
A third alternative is to start an interactive administrative session and using the login com-
mand in the form
login –a admin_user –p <password>
Again the administrator may omit the password in which case he is prompted to enter the
correct password. The interactive session is terminated with the logout command.
The TOE also has parameters an administrator can use to define the password policy.
Those parameters are:
• The minimum length of a password (default: 8)
• The minimum number of alphabetic characters (default: 4)
• The minimum number of non-alphabetic characters (default: 1)
• The maximum number of repeated characters (default: 2)
In addition, the TOE offers to disable administrator accounts for an administrator-defined
amount of time after an administrator-defined number of consecutive unsuccessful authenti-
cation attempts.
6.1.3 F.Authorization
6.1.3.1 Authorization General Model
The authorization model of the TOE is based on Access Control Lists (ACL), “Protected Ob-
ject Policies” (POP) and Access Restriction Extended Attributes. The objects that are pro-
tected (the protected object space) are defined in a tree structure that maintains several
types of objects:
Operating system objects, which represent an operating system resource:
• Files, including programs, directories, soft links, hard links and devices
• Network Connections
• Changing of operating system user ids (surrogate)
Tivoli Access Manager Management Objects, which represent the management objects
that can be managed through the pdadmin interface.
Administrators can define Access Control List policies, “Protected Object Policies” and “Ac-
cess Restriction Extended Attributes” that together build the set of rules the authorization
evaluator subsystem checks to decide if a user can be given the requested type of access
to an object within the protected object space.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 52 2006-02-01
The TOE uses the ACLs also to determine access to management objects within the pro-
tected object space. The semantics of those access modes for the different types of man-
agement objects are described in the following sections. Please note that other access
modes than the ones described with the individual types of management objects have no ef-
fect.
TAMOS RM General Authorization Flow
TAMOS RM components operate in the user-level application space and also within the op-
erating system kernel. Applications access system resources through system-provided
APIs, which arrive in the TAMOS RM operating system kernel extension via the system call
interface.
The primary function of the TAMOS RM operating system kernel extension is to intervene in
accesses to resources that are subject to the authorization policy. The kernel extension
uses the authorization daemon process, PDOSD, to obtain an authorization decision by ap-
plying named authorization policy mechanisms and then enforces that decision. If the policy
permits access to the resource, the operation continues and is then subject to the native
system’s security. Otherwise the resource access is denied.
It should be noted, that TAMOS RM consistently applies this general authorization flow to
TAMOS RM management commands. This yields that only authorized TAMOS RM users
are able to use these commands.
6.1.3.2 Access Control Lists (ACL)
The protected object space is organized as a tree with a single root, addressed by a forward
slash. The next level of hierarchy consists of the Operating Systems Objects (/OSSEAL),
the Tivoli Access Manager Management Objects (/Management) and (eventually) the user-
defined objects.
The leaves within the tree that defines the protected object space are actually the individual
objects. All branches within the tree are called “container objects” since they represent the
container for all the leaves within subtree defined by the “container object”.
Within the Tivoli Access Manager Management Object space, the following categories exist
in the next level of the tree:
• User management objects (/Management/Users)
• Group management objects (/Management/Groups)
• Global Sign On (GSO) management objects (/Management/GSO)
• Server management objects (/Management/Server)
• ACL policy objects (/Management/ACL)
• POP objects (/Management/POP)
• Configuration authorization control objects (/Management/Config)
• Third-party authorization control objects (/Management/Action)
• Authorization database replication control objects (/Management/Replica)
• Domain management (/Management/Domain)
• Authorization rules management (/Management/Rules)
(Categories marked in italics are not used in the TOE configuration)
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 53 2006-02-01
An administrator can create a new object with the pdadmin object command by defining
the fully qualified location within the protected object space (provided he has the required
permission).
An administrator can define and modify Access Control Lists (ACL) for objects within the
protected object space. An ACL consists of:
1. A Type, which can be either “user”, “group”, “any-other” or “unauthenticated”.
The type identifies, if the ACL defines permissions for specific user(s), group(s), any au-
thenticated user or unauthenticated users.
2. An ID, which defines the unique identifier for the user (if of type “user”) or group (if of type
“group”). ACLs of the types “any-other” or “unauthenticated” do not have such an ID.
3. A set of permissions, that define the type of access (action) allowed with the ACL. The
possible permissions are:
Action Description
a Attach
A Add
b Browse
B Bypass POP
c Control
d Delete
g Delegation
l List Directory
m Modify
N Create
r Read
s Server Administration
t Trace
T Traverse
v View
W Password
x Execute
For user and /OSSEAL objects, the semantics of those permissions is defined by the re-
source manager that uses the authorization evaluator and the access manager database for
access decision. The semantics of those permissions within the TOE subsystem are defined
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 54 2006-02-01
later in this chapter.
6.1.3.3 Administration of the Object Space
As mentioned all objects (i. e. representation of objects) in the overall protected object
space build a tree structure with a single root. The tree itself is structured into different “ob-
ject spaces”.
Objects within an object space can be created by an administrator that has the “m” (modify)
permission for the object container where the object is created. Objects can be deleted by
an administrator that has the “d” (delete) permission for the object container of the object.
The following access rights to objects are managed by pdmgrd, since they relate to object
management activities that are not controlled by the resource manager (TAMOS RM):
• b (browse): Permission to browse objects and object spaces using the following admini-
stration commands: objectspace list, object list, object listandshow. Note: The command
object listandshow requires the permission “v” in addition to “b”.
• d (delete): Permission to delete objects and object spaces using the following admini-
stration commands: objectspace delete, object delete, object modify set name. Note: The
command object modify set name requires the permission “m” in addition to “d”.
• m (modify): Permission to create and modify objects and object spaces using the follow-
ing administration commands: objectspace create, object create, object modify. Note:
The command object modify set name requires the permission “d” in addition to “m”.
• v (view): Permission to show object values and attributes using the following administra-
tion commands: object listandshow, object show. Note: The command object listandshow
requires the permission “b” in addition to “v”.
6.1.3.4 ACL Semantics for Management Objects
As mentioned above the TOE uses ACLs also to control access to its own management ob-
jects. The “container objects” (object spaces) that exist for TOE management objects have
been identified in the previous section.
ACLs for management objects can be used to define the commands an administrator is al-
lowed to use with a defined management object. This allows for flexible delegation of spe-
cific administrative tasks to specific administrators or administrator groups.
The following semantics for permissions exist for TOE management objects:
/Management/ACL Permissions :
• d (delete): Permission to delete the ACL policy with the acl delete command. Requires
“c” permission also be become effective.
• m (modify): Permission to create a new ACL policy using the acl create command
• v (view): Permission to find, list and show ACLs using the acl find, acl list and acl show
command
/Management/Action Permissions
This object defines the administrators allowed to manage custom actions. Permissions are:
• d (delete): Permission to delete an existing action or action group using the action delete
and action group delete commands
• m (modify): Permission to create a new action or action group using the action create
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 55 2006-02-01
and action group create commands
/Management/POP Permissions
The object defines the permissions of administrators to manage protected object policies
(POP). Permissions are:
• d (delete): Permission to delete a POP using the pop delete command
• m (modify): Permission to create POPs and modify POP attributes using the pop create
and pop modify commands.
• v (view): Permission to find and list POPs and show POP details using the pop find, pop
list and pop show commands.
• B (Bypass TOD): Permission to overwrite the time-of-day POP attribute on an object us-
ing the acl modify set attribute B command.
/Management/Server Permissions
The object defines the permissions of administrators to perform server management tasks.
Permissions are:
• s (server): Permission to replicate the authorization database using the server replicate
command.
• v (view): Permission to list registered servers and display server properties using the
server list and server show commands.
• t (trace): Permission to enable dynamic trace or statistics administration using the server
task server_name trace and server task server_name stats command.
/Management/Config Permissions
The object defines the permissions of administrators to perform configuration management
tasks. Permissions are:
• m (modify): Permission to define and modify the configuration using the svrsslcfg –
config and svrslcfg –modify commands.
• d (delete): Permission to delete (deconfigure) the configuration using the svrsslcfg –
unconfig command.
/Management/Policy Permissions
The object defines the permissions of administrators to perform policy get and policy set
commands to define or retrieve the overall user related policy attributes (like password re-
strictions, etc). Permissions are:
• v (view): Permission to perform the policy get command.
• m (modify): Permission to perform the policy set command.
/Management/Replica Permissions
The object defines the permission of administrators to control the replication of the master
authorization database. Permissions are:
• v (view): Permission to read the master authorization database
/Management/Users Permissions
The object defines the permissions of administrators to manage user accounts. Permissions
are:
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 56 2006-02-01
• d (delete): Permission to delete a user account using the user delete command.
• m (modify): Permission to modify a user account using the user modify command.
• N (create): Permission to create a user account using the user create and user import
commands.
• v (view): Permission to view a user account and user account details using the user list,
user list-dn, user list-gsouser, user show, user show-dn and user show-groups com-
mand.
• W (password): Permission to reset and validate a user password using the user modify
password and user modify password-valid command.
/Management/Groups Permissions
The object defines the permissions of administrators to manage groups. Permissions are:
• d (delete): Permission to delete a group using the group delete command.
• m (modify): Permission to modify a group using the group modify description and group
modify remove commands.
• N (create): Permission to create a group using the group create and group import com-
mands.
• v (view): Permission to view a group definition using the group list, group list-dn, user,
group show, group show-dn and group show-members command.
• A (add): Permission to a member to a group using the group modify add command.
Further details on the management of the TOE are defined in the description of the function
F.Management.
6.1.3.5 ACL Semantics for Operating System Objects
The TAMOS RM policy is defined under the /OSSEAL root of the object name space. The
next portion of the object name defines the branch name, /OSSEAL/branch-name. Follow-
ing the branch name are the supported TAMOS RM policy types, /OSSEAL/branch-
name/policy-type. The names for the ACL relevant policy types are:
• File
• NetIncoming
• NetOutgoing
• Login
• Surrogate
• Sudo
TAMOS RM permissions are defined by actions within the TOE policy database. An action
defines a single-letter mnemonic representing the permission, the name of the permission,
the kind of the resource it applies to, and the action group of which it is a part. An action
group is a collection of related actions. All TAMOS RM actions are defined as members of
the OSSEAL action group ([OSSEAL]). Actions in the OSSEAL action group represent op-
erations that may be performed on the resources that TAMOS RM protects.
Action Description Resource Type
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 57 2006-02-01
Action Description Resource Type
C Connect NetIncoming and
NetOutgoing
D Change directory File
G Surrogate Surrogate
K Kill program File
L Login Login
N Create File
R Rename File
U Update timestamp File
d Delete File
l List directory File
o Change ownership File
p Change permission File
r Read File
w Write File
x Execute File and Sudo
6.1.3.5.1 Semantics of “NetOutgoing” and “NetIncoming”
TAMOS RM provides the ability to control access to remote network services from a local
machine and also to control access to local network services from remote locations. These
two types of network access are controlled separately by defined, protected resources of
type NetOutgoing and NetIncoming, respectively. These resources are represented in the
Tivoli Access Manager namespace as:
/OSSEAL/policy-branch/NetIncoming/protocol[/service[/host]]
/OSSEAL/policy-branch/NetOutgoing[/hostspec[/protocol[/service]]]
6.1.3.5.2 Semantics of “File”
TAMOS RM provides the ability to control access to file system resources. File systems re-
sources consist of:
• Files
• Directories
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 58 2006-02-01
• Soft links
• Hard links
• Device files
File system resources are represented in the TAMOS RM namespace by defining an object
name with resource type File and specifying the name of the file system resource to be pro-
tected:
/OSSEAL/policy-branch/File/filespec
6.1.3.5.3 Semantics of “Surrogate”
TAMOS RM provides the ability to control operations that can change the UNIX identity of a
process. Such operations are referred to as surrogate operations and are controlled by re-
sources of type Surrogate. Surrogate operations can change the user identity or group iden-
tity of a process. Access control of each of these kinds of surrogate operations is estab-
lished by applying authorization policy to the User and Group sub-types of the Surrogate re-
source type. The object names identify the potential targets of surrogate operations and
control the ability, for example, to surrogate to the root user or the system group. Surrogate
resource names follow the form:
/OSSEAL/policy-branch/Surrogate/User/user-name
/OSSEAL/policy-branch/Surrogate/Group/group-name
6.1.3.5.4 Semantics of “Sudo”
Sudo resources describe commands that require more stringent access control than
whether or not a particular program can be executed. Sudo commands allow access control
based not only on a command but also on the parameters passed to that command. You
can use Sudo commands to remove the requirement for a user to become the root user on
a system in order to perform administrative tasks. Sudo does this by providing the capability
to execute a command as a UNIX user other than that of the invoker. Sudo resources are
identified in the Tivoli Access Manager namespace in the following way:
/OSSEAL/policy-branch/Sudo/sudo-command[/sudo-argclass]
6.1.3.6 Protected Object Policies (POP)
Protected Object Policies contain additional conditions on the request that are passed back
to the resource manager (in the case of the TOE: TAMOS RM) in the case the evaluation of
the ACLs for the request was positive (i. e. according to the ACL policy request is granted).
For those conditions of a POP it is the responsibility of the resource manager to enforce the
conditions defined by the “Protected Object Policy”.
The following attributes can be set in a “Protected Object Policy”:
• Warning Mode. This attribute is used for debugging purpose mainly. Possible values
are: “yes” and “no”. If set to “yes”, all decisions result in a “permit” being returned (no
policies are enforced), and audit records are generated that capture the result of all ACL
authorization decisions that would have been made if the warning mode would have
been set to “no”.
• Audit Level. This attribute defines the level of audit for the object. Possible values are:
“permit”, “deny” and “error”. (The audit level “error” is not supported by TAMOS RM.) In
the case of “permit”, all requests on a protected object that result in successful access
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 59 2006-02-01
are audited. In the case of “deny”, all requests on a protected object that result in denial
of access are audited. In the case of “error”, all internally generated error messages re-
sulting from the denial of access to the protected object are audited.
• Time-of-Day. This attribute defines the day and time conditions on the access to a pro-
tected object. This attribute is overwritten by the “B” (Bypass POP) ACL policy permis-
sion.
• Authentication Strength. (Not supported by TAMOS RM) This attribute can be used to
define restrictions on the authentication method required to gain access to the protected
object. This is useful, if access to the object requires a high grade of confidence in the
correct authentication of the user. It is the task of the resource manager to ensure that
the user has authenticated with required authentication method before granting access to
the object.
• Network-based Authentication. (Not supported by TAMOS RM) This attribute allows to
control access based on the IP address of the user. This can be used to prevent access
to protected objects from specific IP addresses or range of IP addresses.
• Quality of Protection. (Not supported by TAMOS RM) This attribute allows to define the
required level of protection for an object. Possible values are: “Privacy” and “Integrity”. In
the case of “Privacy” the resource manager has to ensure that the object is transferred
over an SSL encrypted communication link. In the case of “Integrity” the resource man-
ager has to ensure that a mechanism for the protection of the integrity of the object is
used when transferred.
6.1.3.7 Access Restriction Extended Attributes
TAMOS RM defines an extended attribute on an ACL which enables control over what pro-
grams users can use to perform particular actions. The name of the attribute is Access-
Restrictions. Access to resources is controlled based on the identity of the user, the action
that the user is performing, and the current program being used to perform the action. This
restriction is in addition to the access control enforced by the base ACL that the attribute is
associated with. Before an access restriction is applied the user must first have been
granted access by the base ACL entries.
The format for an extended attribute Access-Restrictions entry is:
rule : accessor : permission-set : program-set
6.1.3.8 ACL Evaluation
ACLs may be either explicit or inherited. Any object without an explicit ACL inherits the ACL
of the container object above in the object space tree. Note that this container object may
also just have an inherited ACL. The root object must always have an ACL. A default ACL
for this object is set at the TOE installation and initial configuration.
The TOE uses the following rule to determine if an authenticated user has the permission
for the action requested for a defined object within the protected object space
(Note: When checking for the existence of an ACL for an object, it always means checking
for an explicit or inherited ACL):
1. Check that the user has the traverse permission for all container objects on the path
from the root container object down to the actual object. To check this, use the steps 2 to
4 of this algorithm for all container objects on the path and the “Traverse” (T) permission.
2. Check if an ACL entry of type “user” exists for the user and the object. If this is the case,
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 60 2006-02-01
permission is granted if the requested action is defined in the ACL entry. The ACL
evaluation algorithm stops if the permission is granted.
3. Check if ACL entries of type “group” exist for the groups the user belongs to and the ob-
ject. If they exist, check if the requested permission is contained in at least one of those
entries. If yes, the permission is granted and the evaluation algorithm stops.
4. Check if an ACL entry of type “any-other” exists for the object. If yes, check if the per-
mission is granted within this ACL entry. If yes, permission is granted. Permission is de-
nied, if it is not granted by the “any-other” ACL entry or if the ACL entry of type “any-
other” does not exist for the object.
The TOE uses the following rule to determine if an unauthenticated user has the permission
for the action requested for a defined object within the protected object space.
1. Check that unauthenticated users have the traverse permission for all container objects
on the path from the root container object down to the actual object. To check this, use
the steps 2 to 4 of this algorithm for all container objects on the path and the “Traverse”
(T) permission.
2. Check if an ACL entry of type “unauthenticated” exists for the object. If no such ACL en-
try exists, access is denied and the evaluation algorithm stops.
3. Check if an ACL entry of type “any-other” exists for the object. If no such ACL entry ex-
ists, access is denied and the evaluation algorithm stops.
4. Check if the requested access is granted in both the ACL entries of type “unauthenti-
cated” and in the ACL entries of type “any-other” for the object. Access is granted if the
requested type of access is granted in both ACL entries. Otherwise access is denied.
As a result, a user has the requested access to an object if the two following conditions are
satisfied:
1. The user has traverse permission for all container objects on the path from the root down
to the object
2. The user has the requested permission being explicitly granted by the object’s ACL,
which may be an explicit ACL or an inherited ACL.
6.1.3.9 Access Restriction Evaluation
If the user is authenticated, entries with accessor values of user, group, and any-other ap-
ply. Only the attribute entries whose permission set contains all of the permissions associ-
ated with the actions being performed against the protected resource are evaluated to see if
they apply to the current access decision. For example, if read and write access is re-
quested, then only entries with both the r and w permissions (and possibly others) are con-
sidered. Entries with a permission set value of * match all access requests regardless of the
action being performed.
Entries with the accessor type user have the highest precedence during evaluation:
• if a deny rule entry is found with a user accessor type and the specified name matches
the accessing user’s name and the user’s program or * is included in its program set, ac-
cess is denied;
• if a permit rule entry is found with a user accessor type and the specified name matches
the accessing user’s name and the user’s program or * is included in the entry’s program
set, access is granted;
• if access has not been granted by other user accessor type entries and a permit rule en-
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 61 2006-02-01
try is found with a user accessor type and the specified name matches the accessing
user’s name and the user’s program or * is not included in the entry’s program set; ac-
cess is denied;
If no matching user accessor entries are found, entries with the group accessor type are
evaluated:
• if a deny rule entry is found with a group accessor type and the specified name matches
a group the accessing user is a member of and the user’s program or * is included in its
program set, access is denied;
• if a permit rule entry is found with a group accessor type and the specified name matches
a group the accessing user is a member of and the user’s program or * is included in its
program set, access is granted;
• if access has not been granted by other group accessor type entries and a permit rule
entry is found with a group accessor type and the specified name matches a group the
accessor is a member of and the user’s program or * is not included in the entry’s pro-
gram set; access is denied;
If no matching user or group accessor entries are found, entries with the any-other accessor
type are evaluated:
• if a deny rule entry is found with an any-other accessor type and the user’s program or *
is included in its program set, access is denied;
• if a permit rule entry is found with an any-other accessor type and the user’s program or *
is included in its program set, access is granted;
• if access has not been granted by other any-other accessor type entries and if a permit
rule entry is found with an any-other accessor type and the user’s program or * is not in-
cluded in the entry’s program set, access is denied.
If the user is unauthenticated, only entries with accessor value unauthenticated apply. As
with authenticated users, only the attribute entries whose permission set contains all of the
permissions associated with the actions being performed against the protected resource are
evaluated to see if they apply to the current access decision:
• if a deny rule entry is found with an unauthenticated accessor type and the user's pro-
gram or * is included in its program set, access is denied;
• if a permit rule entry is found with an unauthenticated accessor type and the user’s pro-
gram or * is included in the entry’s program set, access is granted;
• if access has not been granted by other unauthenticated accessor type entries and if a
permit rule entry is found with an unauthenticated accessor type and the user’s program
or * is not included in the entry’s program set; access is denied.
If no Access-Restrictions attribute entries apply that deny access, the access granted by the
base ACL still applies and access is granted.
6.1.3.10 Dropping access credentials
Users can “drop” their access credentials and spawn an operating system shell that is there-
fore treated as “unauthenticated” by TAMOS by using the pdosunauth command.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 62 2006-02-01
6.1.4 F.Management
6.1.4.1 Tivoli Access Manager Administrators
At installation the TOE the group “iv-admin” is created with an initial administrator
“sec_master” as its member. In addition a default ACL is defined for the “root” object in the
protected object space. This default ACL for this object is:
Group iv-admin TcmdbvaBR
Any-other T
Unauthenticated T
This default-root ACL allows everyone to traverse the object space (T) in order to pass
through the object and gain access to protected resource objects further down in the hierar-
chy, while only members of the group iv-admin are allowed to perform the following actions:
control as owners (c), modify (m), delete (d), browse (b), view (v), attach (a), override the
POP policy (B) and override the authorization rule policy (R).
There are also default values for the different management object spaces, which are defined
in the Base Administrator’s Guide.
The mechanisms described in F.Authorization allow the initial administrator to define other
administrators and/or administration groups and assign them the right to perform only spe-
cific administration tasks. This is achieved by assigning them the appropriate permissions
for the individual management object spaces and objects within those object spaces as well
as the appropriate permissions to individual objects or object spaces within the overall user
object space.
6.1.4.2 User and Group Management
Users are managed on the host operating system in combination with an external LDAP
server holding the login policy and user credentials. An administrator with the appropriate
permission in the /Management/User object space can perform user management opera-
tions like creating users, deleting users or changing the user's login policy. The commands
to create and manage user accounts are defined in the Command Reference. The required
access rights to perform the commands are defined in section 6.1.3.4 under
“/Management/Users”.
Groups are managed using the pdadmin group set of commands. The required access
rights to perform the commands are defined in section 6.1.3.4 under
“/Management/Groups”.
Users can be assigned to more than one group. Section 6.1.3.8 describes, how access
rights to objects are evaluated which includes the evaluation of access rights in the case a
user belongs to more than one group.
6.1.4.3 ACL, POP and Access Restriction Extended Attributes Management
ACLs are managed using the pdadmin acl set of commands defined in the Command Ref-
erence. The required access rights to perform the commands are defined in section 6.1.3.4
under “/Management/ACL”.
Protected Object Policies are managed using the pdadmin pop set of commands. The re-
quired access rights to perform the commands are defined in section 6.1.3.4 under
“/Management/POP”.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 63 2006-02-01
Access Restriction Extended Attributes are managed using the pdadmin acl set of com-
mands defined in the Command Reference. The required access rights to perform the
commands are defined in section 6.1.3.4 under “/Management/ACL”.
6.1.4.4 TOE Certificate Management
The TOE maintains its own Certification Authority and certificate management functions for
the certificates it needs for authentication and key exchange between different servers that
are part of the TOE (i. e. TOE internal communication). The single pdmgrd instance within
the TOE also acts as the Certification Authority for the TOE internal public key infrastruc-
ture.
During installation of the TOE management subsystem (pdmgrd instance), two RSA key
pairs (key size 1024 bit) need to be generated. One of those key pairs is used as the CA
key to sign certificates (PDCA key), the other one is used for authentication when setting up
a SSL v3 connection to another server within the TOE (pdmgrd-SSL key). The TOE man-
agement subsystem will then create a self-signed certificate for the PDCA public key and
also sign the pdmgrd-SSL key using the PDCA private key.
Certificates and private keys of TOE components are held in special files (“keyring files”).
Protection of those files against unauthorized access and modification is essential for the
security of the TOE.
If a server’s private key is compromised (or needs to be revoked for other reasons) the ad-
ministrator can do this using the chgcert command. This will require creating a new key pair,
generate a certificate for the public key and invalidate the old certificate (by removing it from
the keyring files of all servers that are part of the TOE).
6.1.4.5 Login Policy Management
TAMOS RM lets the administrator control when and from where a user can log in to a sys-
tem. The basic mechanisms for controlling user access are:
• Defining time-of-day login restrictions for users independent of where they log in from
• Defining access controls on local and remote terminals.
TAMOS RM also provides the ability to enforce login-activity-related policy such as pass-
word expiry, automatically disabling accounts after a number of failed logins, and automati-
cally disabling inactive accounts.
Time-of-day login restrictions are defined by specific policy attributes in the user registry.
They can be specified globally, on a per-user basis, or specifically for unauthenticated us-
ers. Time-of-day restrictions define hours of the day and days of the week during which us-
ers are permitted to log in. For users defined in the user registry, any user-specific policy
overrides any global policy.
A time-of-day restriction is defined by a string of the following format:
day-range:time-range[:utc|local]
Holiday login restrictions specify additional time-of-day restrictions by defining Holidays.
Holidays are protected resources that define exceptions to the regular time-of-day restric-
tions defined in the user registry. Holiday policy is applied when a user logs in.
The ability of a user to log in on the holiday is controlled by the ACL attached to the same
resource. The Login (L) permission must be granted to those users allowed to log in. The
format of the value of the Holiday-Dates extended attribute is a start time followed by an op-
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 64 2006-02-01
tional space and an end time. The specified time format follows:
YYYY-MM-DD[-hh[:mm[:ss]]][Z]
The names of the holiday objects are are:
/OSSEAL/policy-branch/Login/Holiday/holidayname
Login location restrictions specify where users can log in. Protected resources are de-
fined under the Terminal branch of the Login resource hierarchy to specify where users can
log in. Login locations are referred to as terminals.
Local and remote terminals: Terminals are either local or remote. Terminals are local when
used for logins to a system from serial devices and graphical consoles. Terminals are re-
mote when used across a TCP/IP network. You can group both kinds of terminals together
and use inheritance to define access controls. The names of terminal objects follow the for-
mat:
/OSSEAL/policy-branch/Login/Terminal/Local/termgroup/device
/OSSEAL/policy-branch/Login/Terminal/Remote/termgroup/hostspec
Login activity policy TAMOS RM provides the ability to define and enforce policy related to
login activity. The policy is defined centrally by using extended attributes of the
/OSSEAL/policy-branch/Login
object and controls the following aspects of login activity:
• Password expiry
• Account suspensions due to failed login attempts
• Account lockouts due to account inactivity
The status of each user account is recorded on a per-machine basis. Accounts become
locked or suspended only on the machine on which they have been active or on which failed
login attempts have occurred. Password expiry times are maintained on a per-machine ba-
sis. TAMOS RM login activity policy is applied in addition to any such policy provided
natively by the operating system. The more restrictive between the TAMOS RM policy and
the operating system policy will apply.
User exception policy allows defining exceptions to the default login activity policy. This
capability is provided strictly as a mechanism to define exceptions to the default policy and
should not be used to define login activity policy for a large number of users. The user ex-
ception policy is defined by setting the login activity extended attributes on the
/OSSEAL/policy-branch/Login/UserExceptions/user-name
object. Only attributes that are explicitly set for this object apply to the user. Any login activ-
ity extended attribute not explicitly set is given a value of zero. These unspecified attributes
do not inherit the value from the default login activity extended attributes.
6.1.4.6 Password Management
TAMOS RM provides the ability to define and enforce policy related to password manage-
ment. Password management prevents users from specifying weak passwords that are vul-
nerable to compromise by methods such as a dictionary attack. The policy is defined cen-
trally by using extended attributes of the:
/OSSEAL/policy-branch/Password
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 65 2006-02-01
object and controls the following aspects of password management activity:
• Password strength
• Password aging
TAMOS RM password management policy is applied in addition to any such policy provided
natively by the operating system. The more restrictive between the TAMOS RM and the op-
erating system policy will apply. It is possible that the password will be modified by the na-
tive operating system prior to the TAMOS RM password enforcement modules seeing the
password. If this happens, the password management policy will be applied to the modified
password. For example, if the operating system truncates the password to the number of
characters it considers significant, the password management policy is applied to the trun-
cated password.
6.1.4.7 Audit management
The Policy Server provides a configuration file allowing defining parameters such as audit
trail location and roll over functionality for those files.
For the configuration of auditable events related to transactions controlled by POPs, refer to
section 6.1.3.6.
6.1.4.8 TAMOS RM Management
TAMOS RM provides management commands for the following aspects:
• pdoslpadm – unlocking (and locking) of locked users. The login policy's lockout aspect is
immediately changed either allowing access (unlock) or denying it (lock).
• pdosrefresh – refresh the credentials for a user with information obtained from the user
registry. The user's credentials are immediately replaced by information obtained from
the user registry.
• pdosdestroy – destroys the cached credentials for a user, resulting in a refresh of the
credentials at next access.
• pdosctl – manages several operational aspects, such as the generation of audit records
and the start/stop of daemons
• pdoscfg - configures Tivoli Access Manager for Operating Systems
• pdoshla - manages the IP address to Host Name Lookaside Database
• pdosrgyimp - imports UNIX users and groups into the Tivoli Access Manager user regis-
try
• pdosshowuser - shows various attributes of a specific user
• pdoswhoami - displays the Tivoli Access Manager for Operating Systems accessor ID in-
formation
• pdoswhois - displays Tivoli Access Manager for Operating Systems accessor ID informa-
tion associated with the specified process Ids
It should be noted, that the execution of these commands is controlled by the centrally man-
aged access control policy and access is therefore possible only for authorized users.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 66 2006-02-01
6.1.5 F.Communication
Communication between the TOE and the LDAP server are protected by SSL v3. The TOE
acts as a client system for the communication with the LDAP server.
The TOE also uses SSL v3 to protect the communication between different servers that are
part of the TOE. This communication always requires client and server authentication using
digital certificates. The management of those certificates is part of the security function
F.Management.
The TOE uses the GSKit component to implement the SSL Version 3 protocol and the cer-
tificate management functions required. The certificate management functions are ad-
dressed under F.Management.
The SSL protocol itself is defined in [SSLv3] and [RFC2246]. The TOE supports the follow-
ing cipher suites defined in those standards:
• CipherSuite SSL_RSA_WITH_NUL_MD5
• CipherSuite SSL_RSA_WITH_NUL_SHA
• CipherSuite SSL_RSA_EXPORT_WITH_RC4_40_MD5
• CipherSuite SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
• CipherSuite SSL_RSA_WITH_DES_CBC_SHA
• CipherSuite SSL_RSA_WITH_RC4_128_MD5
• CipherSuite SSL_RSA_WITH_RC4_128_SHA
• CipherSuite SSL_RSA_WITH_3DES_EDE_CBC_SHA
Only SSL_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_MD5 and
SSL_RSA_WITH_3DES_EDE_CBC_SHA for SSL v3 are considered part of the evaluation.
Those cipher suites are configured as the only cipher suites employed in the evaluated con-
figuration, i.e. the TOE will choose them if they are supported by the client and not establish
a connection if the client does not use one of those cipher suites.
6.2 TSF that are subject to a Strength of Function Analysis
All TSF that are based on probabilistic or permutational algorithms are subject to a strength
of function analysis except those that use cryptographic algorithms. The function subject to
an SOF rating is:
• F.Authentication (SOF-medium)
Within F.Authentication only the password-based mechanism for the authentication of Base
Administrators is within the scope of the strength of function analysis.
The Common Criteria exclude the rating of cryptographic mechanisms including key genera-
tion. This Security Target does not make any claim on the strength of such mechanisms.
6.3 Statement of Assurance Measures
The following table provides an overview how the assurance measures of EAL3 and
ALC_FLR.1 are satisfied:
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 67 2006-02-01
Assurance
Component
Assurance measures
ACM_CAP.3 IBM uses various configuration management tools, such as CMVC and
Lotus Notes data bases, for source code, design documentation, guid-
ance, testing, etc.
ACM_SCP.1 As mentioned above, source code, design documentation, user and ad-
ministrator documentation as well as test documentation are maintained
within CM systems.
ADO_DEL.1 Delivery procedures are described as part of the developer documenta-
tion. This includes also the measures taken to ensure the integrity and
authenticity of the TOE during the delivery process.
ADO_IGS.1 The guidance documentation provided to the customer includes a de-
tailed description how to install and configure the individual components
that define the TOE. Additional guidance for the installation and configu-
ration of exactly the evaluated configuration is provided as part of the
guidance documentation.
ADV_FSP.1 The TSFI are identified in a separate document which points to the
documents describing the different interfaces.
ADV_HLD.2 High level design documents exist that describes the internal structure of
the TOE into subsystems, how the security functions of the TOE are im-
plemented and how the subsystems contribute to the security functions.
ADV_RCR.1 Correspondence between the TSF as defined in the TOE summary
specification and the functional specification as well as correspondence
between the functional specification and the high level design is provided
in form of commented tables that show the correspondence.
AGD_ADM.1 Administrator guidance documents exist for the Policy Server as well as
for TAMOS RM as the Resource Manager / Authorization Evaluator used
in the TOE. They describe the administrative tasks, the commands to be
used and the different management aspects.
AGD_USR.1 There is no user guidance required for the TOE, since the user can be
anybody that tries to access protected resources and users will not need
to know anything about the security functions of the TOE. Organizations
using the TOE within their environment have to educate their users to
satisfy the requirements for protecting their passwords or private keys.
Assumptions on user behavior in the TOE environment are postulated in
the administrator guidance.
ALC_DVS.1 The security measures for the IBM development environment are de-
rived from the IBM Global documents that define the minimum require-
ments for the physical and organizational security.
ALC_FLR.1 Problems that are reported either from the development process or by a
customer will result in a “defect” that is managed with CMVC. Defects
are classified with respect to their impact and one of the possible classi-
fications is “security”. Since all defects are tracked and managed by
CMVC, it is easily possible to extract all security relevant defects, their
status and what has been done to fix them.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 68 2006-02-01
Assurance
Component
Assurance measures
ATE_COV.1 Testing is performed as functional verification testing using a defined test
suite in accordance with defined test procedures as described in the test
plan. Coverage of security functions is provided in form of a table show-
ing which test cases test which security functions at which interface. The
table shows that all security functions and their parameter are tested at
the interfaces defined in the functional specification.
ATE_DPT.1 A mapping is produced that shows the mapping of test cases to details
defined in the high level design. The mapping shows that those details
are covered by test cases and the test cases themselves show that the
TOE operates in accordance with its high level design.
ATE_FUN.1 A test plan is provided that describes the test procedures, test cases,
purpose of each test and expected results. Records of actual tests per-
formed and their results are maintained under CM.
ATE_IND.2 Independent testing is performed as part of the evaluation by the evalua-
tion facility. The test plan and test cases as well as the TOE suitable for
testing will be provided to the evaluation facility such that all the test
cases can be performed by the independent evaluator.
AVA_MSU.1 An analysis of the user provided documentation describing the installa-
tion and configuration, the administrator interface and commands and
the configuration files is performed by the evaluation team to ensure that
those documents are consistent and provide all the required guidance
for an administrator to install, configure and administer the TOE in a se-
cure manner.
AVA_SOF.1 A strength of function analysis is provided for the mechanisms based on
permutational or probabilistic properties (except for cryptographic
mechanism) to demonstrate that those mechanisms have a strength of
SOF-medium or better.
AVA_VLA.1 A process is in place and documented to search for vulnerabilities of the
TOE using open sources of vulnerabilities on the Internet like CVE or
CERT advisories. The results of this process are documented and pro-
vide the developer vulnerability analysis as required.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 69 2006-02-01
7 PP claims
This Security Target does not claim compliance with any existing Protection Profile.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 70 2006-02-01
8 Rationale
This chapter provides the rationale for the selection of security objectives and requirements
within APP.
8.1 Security Objectives Rationale
8.1.1 Security Objectives Coverage
The mapping in Table 2 indicates how each security objective for the TOE is traced back to
at least one threat or organizational security policy.
Objective threat / OSP
O.AUTHORIZATION T.BYPASS, T.UAUSER
O.AUTHENT_ADMIN T.UAUSER
O.ACC_ADM P.ADM_DELEGATION,
O.AUDITING T.UAUSER, T.UAACTION
P.ACCOUNTABILITY
O.SEC_COM T.UAUSER, T.COM_ATT
O.SOF T.UAUSER
Table 2: security objectives traced back to threats and organizational security policies
The mappings in Table 3 and Table 4 indicate how each security objective for the environ-
ment is traced back to at least one assumption, threat or organizational security policy.
Objective (IT Environment) threat / OSP / assumption
OE.OS_TIME T.UAACTION (supportive)
P.ACCOUNTABILITY
OE.OS_CFG_PROT TE.BYPASS
P.ACCOUNTABILITY
OE.DS_ACCESS_CTRL A.DIR_PROT
OE.FRIENDLY_DS T.UAUSER (supportive)
A.DIR_PROT
A.FRIENDLY_LDAP
OE.REPLICAS A.DIR_PROT
OE.OS_AUTH T.UAUSER (supportive)
A.USER_PASSWORD
OE.SEPARATION TE.BYPASS
A.FRIENDLY_OS
Table 3: security objectives for the IT environment traced back to threats, organizational se-
curity policies and assumptions
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 71 2006-02-01
Objective (non-IT Environ-
ment)
threat / OSP / assumption
OE.INSTALL A.ADMIN
OE.CREDEN A.PWD_SAFE
OE.PHYSICAL A.ADMIN, A.PHYS_PROT
OE.OS_OPERATE A.ADMIN, A.BOOT, A.OS_CONF_MGMT
OE.SEC_INTEGRATE A.ADMIN, A.DIR_PROT, A.FRIENDLY_OS
OE.USER A.ADMIN, A.USER
Table 4: security objectives for the non-IT environment traced back to threats, organizational
security policies and assumptions
8.1.2 Security Objectives Sufficiency
The following arguments provide justification that the security objectives are suitable to
counter each single threat and that each security objective tracing back to a threat, when
achieved, actually contributes to the removal, diminishing or mitigation of that threat:
The threat T.BYPASS, imposing that an attacker uses non-TSF portions of the TOE to by-
pass the TSF, is removed by O.AUTHORIZATION requiring an implementation of the TOE
that enforces access control before any transaction is allowed. Note that bypassing the TOE
completely is addressed by the threat TE.BYPASS discussed below.
T.UAACTION imposes the threat of an attacker to perform unauthorized, TSP-violating ac-
tions without detection of those actions. This threat is removed by O.AUDITING requiring
the TSF to log security relevant actions, supported by OE.TIME providing a reliable time
source.
The threat of an attacker impersonating an authorized user, T.UAUSER, is efficiently dimin-
ished by O.AUTHENT_ADMIN requiring authentication for the TOE’s administrators, sup-
ported by OE.OS_AUTH in the IT environment (see below) and further mitigated by
O.AUDITING implementing audit records for security relevant actions. In addition
O.SEC_COM prohibits that authentication credentials can be intercepted while transferred
via the network connections. Note that this is further supported by OE.FRIENDLY_DS, since
authentication decisions are derived from the external LDAP server. O.SOF additionally di-
minishes this threat by requiring strong passwords by means of a mandatory password pol-
icy.
The threat of an attacker intercepting and/or modifying the communication traffic between
the TOE and an external entity or between physically distributed parts of the TOE,
T.COM_ATT, is efficiently diminished by O.SEC_COM requiring that all communication be-
tween physically separated parts of the TOE is protected to maintain its confidentiality and
integrity.
Attackers using functions in the IT environment to circumvent TSF, as outlined in
TE.BYPASS, are prevented from succeeding by OE.SEPARATION demanding support of
the underlying operating system in providing a security domain for the resource manager
systems and OE.OS_CFG_PROT requiring protection of configuration files for the policy
server.
The following arguments provide justification that the security objectives are suitable to
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 72 2006-02-01
cover each single organizational security policy, that each security objective that traces back
to an OSP, when achieved, actually contributes to the implementation of the OSP, and that
if all security objectives that trace back to an OSP are achieved, the OSP is implemented.
P.ACCOUNTABILITY requires accounting for actions of administrators and access decision
requests made by any user. This is covered by O.AUDITING containing the requirement of
audit records for those very actions. The creation of audit records is supported by the envi-
ronment as required in OE.OS_TIME by providing an accurate time source to be included in
those records. In addition OE.OS_CFG_PROT supports this policy and requires that the
audit configuration file is protected against unauthorized access.
The TOE shall allow the delegation of administrative tasks to manage only access control
policy rules related to a dedicated subset of objects (targets) as in P.ADM_DELEGATION.
This is implemented by O.ACC_ADM providing means to control the (management) access
to certain access control policy rules by, again, access control policy rules (in this case, the
targets of an access control decision request initiated by an administrator are access control
policy rules related to a certain object space in the TOE environment).
The following arguments provide justification that the security objectives for the environment
are suitable to cover each single assumption, that each security objective for the environ-
ment that traces back to an assumption about the environment of use of the TOE, when
achieved, actually contributes to the environment achieving consistency with the assump-
tion, and that if all security objectives for the environment that trace back to an assumption
are achieved, the intended usage is supported.
The assumption on physical protection for the underlying machine of the TOE,
A.PHYS_PROT, is covered by OE.PHYSICAL requiring protection of those machine(s) from
unauthorized physical access.
The assumption A.PWD_SAFE on the protection of authentication credentials by adminis-
trators and other users of the TOE is achieved by OE.CREDEN requiring that appropriate
measures for the protection of access credentials are ensured by the responsible personnel.
A.ADMIN assumes that administrators of the TOE and the underlying systems are trained,
trustworthy and follow the guidance. This is covered by OE.INSTALL requiring competent
and trustworthy administrators that deliver, install, manage and operate the TOE in a man-
ner which maintains the IT security objectives and by OE.OS_OPERATE which makes
dedicated requirements on the operation and configuration of the underlying machines host-
ing the TOE application. This is in addition achieved by the objectives OE.PHYSICAL,
OE.SEC_INTEGRATE and OE.USER, expecting administrators to implement physical pro-
tection, secure integration of the TOE and the provision of guidance to users.
A.OS_CONF_MGMT assumes the reliable configuration and maintenance of the underlying
operating system, emphasizing on the prevention of unauthorized (local or remote) access
to operating system functions including network daemons. This is achieved by
OE.OS_OPERATE which includes the demand for an appropriate installation, configuration
and maintenance of the underlying operating system.
The assumption A.DIR_PROT assumes that protection features for the directory server
used by the TOE exist, which prohibit unauthorized access to directory entries. This is
achieved by the objective OE.DS_ACCESS_CTRL requiring the directory server to control
the access to directory entries. Furthermore, OE.REPLICAS requires that a clear policy is
implemented on how the LDAP server provides for the consistent replication of TSF data. In
addition OE.FRIENDLY_DS requires that the LDAP server’s support functions for the TOE
behave as specified, and OE.SEC_INTEGRATE stipulates protection of the communication
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 73 2006-02-01
between TOE and directory server.
The assumption A.USER is addressed by the objectives OE.USER which requires that the
persons responsible for the TOE control the user community that can request access to re-
sources protected by the TOE.
The assumption A.FRIENDLY_LDAP assumes the LDAP server in the IT environment to
behave as specified. This is of relevance for OE.DS_ACCESS_CTRL and
OE.FRIENDLY_DS, since the authentication, authorization and replication mechanisms of
the LDAP server support the operation of the TSF.
The assumption A.FRIENDLY_OS assumes the operating system in the IT environment to
be well behaved and cooperative with regard to supporting the TSF. This is achieved by the
objective OE.SEPARATION, demanding support of the underlying operating system in pro-
viding a security domain for the resource manager systems. As a supportive means con-
sumers of the TOE are encouraged in OE.SEC_INTEGRATE to gain additional assurance
that the underlying operating system works as specified.
8.2 Security Requirements Rationale
This chapter provides the rationale for the selection of security requirements within APP. In
addition to this rationale, chapter 5 includes application notes for several security functional
requirements to further improve the interpretation of those requirements with respect to an
APP-conformant implementation of the TOE.
8.2.1 Security Requirements Coverage
The following tables illustrate which security objectives are implemented by which security
functional requirements. Table 5 indicates how each TOE security functional requirement
can be traced back to at least one security objective for the TOE, Table 6 indicates how
each functional security requirement for the IT environment can be traced back to at least
one security objective for the environment.
SFR Objective
FAU_GEN.1 O.AUDITING
FAU_GEN.2 O.AUDITING
FAU_GEN.3-TAMOS O.AUDITING
FAU_SAR.1(1) O.AUDITING
FAU_SAR.1(2) O.AUDITING
FAU_SEL.1(1) O.AUDITING
FAU_SEL.1(2) O.AUDITING
FAU_STG.1 O.AUDITING
FCS_CKM.1(1) O.SEC_COM
FCS_CKM.1(2) O.SEC_COM
FCS_CKM.2(1) O.SEC_COM
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 74 2006-02-01
SFR Objective
FCS_CKM.2(2) O.SEC_COM
FCS_COP.1(1) O.SEC_COM
FCS_COP.1(2) O.SEC_COM
FDP_ACC.2(1) O.AUTHORIZATION
FDP_ACC.2(2) O.ACC_ADM
O.AUTHORIZATION
FDP_ACF.1 (1) O.AUTHORIZATION
FDP_ACF.1 (2) O.ACC_ADM
O.AUTHORIZATION
FIA_AFL.1(1) O.AUTHENT_ADMIN
O.SOF
FIA_AFL.1(2) O.SOF
FIA_ATD.1(1) O.AUTHORIZATION
FIA_ATD.1(2) O.ACC_ADM
O.AUTHENT_ADMIN
O.AUTHORIZATION
FIA_SOS.1 O.SOF
FIA_UAU.2 O.AUTHENT_ADMIN
FIA_UID.1 O.AUDITING
O.AUTHORIZATION
FIA_UID.2 O.AUDITING
O.AUTHENT_ADMIN
O.ACC_ADM
O.AUTHORIZATION
FIA_USB.1 O.AUDITING
O.AUTHENT_ADMIN
O.ACC_ADM
O.AUTHORIZATION
FMT_MOF.1 O.ACC_ADM
FMT_MSA.1(1) O.ACC_ADM
FMT_MSA.1(2) O.ACC_ADM
FMT_MSA.2 O.ACC_ADM
O.SEC_COM
FMT_MSA.3 O.ACC_ADM
FMT_MTD.1 O.ACC_ADM
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 75 2006-02-01
SFR Objective
FMT_SMF.1 O.AUDITING
O.AUTHENT_ADMIN
O.ACC_ADM
O.AUTHORIZATION
O.SOF
FMT_SMR.1 O.ACC_ADM
FPT_ITT.1 O.SEC_COM
FPT_RVM.1 O.ACC_ADM
O.AUTHORIZATION
FPT_TRC.1 O.SEC_COM
FTP_ITC.1 O.SEC_COM
Table 5: SFRs for the TOE traced back to objectives for the TOE
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 76 2006-02-01
SFR (environment) Objective (environment)
Operating System for Policy Server
FIA_UID.1 OE.OS_CFG_PROT
FMT_MTD.1 OE.OS_CFG_PROT
FMT_SMF.1 OE.OS_CFG_PROT
FMT_SMR.1 OE.OS_CFG_PROT
FPT_SEP.1 OE.OS_CFG_PROT
FPT_STM.1 OE.OS_TIME
LDAP Server
FDP_ACC.1 OE.DS_ACCESS_CTRL
FDP_ACF.1 OE.DS_ACCESS_CTRL
FDP_ETC.1 OE.DS_ACCESS_CTRL
FDP_ITC.1 OE.DS_ACCESS_CTRL
FIA_UAU.2 OE.DS_ACCESS_CTRL, OE.FRIENDLY_DS
FIA_UID.2 OE.DS_ACCESS_CTRL
FMT_MSA.1 OE.DS_ACCESS_CTRL, OE_FRIENDLY_DS
FMT_MSA.3 OE.DS_ACCESS_CTRL
FMT_SMF.1 OE.DS_ACCESS_CTRL
FMT_SMR.1 OE.DS_ACCESS_CTRL
Operating System for TAMOS RM
FDP_ACC.1 OE.OS_CFG_PROT
FDP_ACF.1 OE.OS_CFG_PROT
FIA_ATD.1 OE.OS_CFG_PROT
FIA_UAU.1 OE.OS_AUTH
FIA_UID.1 OE.OS_AUTH
FIA_USB.1 OE.OS_AUTH
FMT_MSA.1 OE.OS_CFG_PROT
FMT_MSA.3 OE.OS_CFG_PROT
FMT_MTD.1 OE.OS_CFG_PROT
FMT_SMF.1 OE.OS_CFG_PROT
FMT_SMR.1 OE.OS_CFG_PROT
FPT_SEP.1 OE.SEPARATION
FPT_STM.1 OE.OS_TIME
Table 6: SFRs for the environment traced back to objectives for the environment
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 77 2006-02-01
8.2.2 Security Requirements Sufficiency
The following arguments provide justification for each security objective for the TOE that the
TOE security requirements are suitable to meet and achieve that security objective.
O.AUTHORIZATION requires that only authorized administrators and users gain access to
the TOE and the resources it protects. For administrators, the TOE implements access con-
trol as in FDP_ACC.2(2) and FDP_ACF.1(2), the access control policy for users is modeled
in FDP_ACC.2(1) and FDP_ACF.1(1). Access control contributes to the non-bypassability of
the TSF (FPT_RVM.1). The implementation of the access control policies is supported by
the ability to identify users (FIA_UID.1, FIA_UID.2), user-subject binding (FIA_USB.1), ap-
propriate attributes (FIA_ATD.1(1), FIA_ATD.1(2)), and management functionality for ac-
cess control (FMT_SMF.1).
O.AUDITING requires the ability to audit security relevant actions of users and administra-
tors. FAU_GEN.1 and FAU_GEN.3-TAMOS specify the types of audit events that can be
recorded; FAU_GEN.2 ensures that those records are associated with the originating user
identity (as far as possible). FAU_SEL.1(1) and FAU_SEL.1(2) allow administrators to select
levels of audits. FAU_SAR.1(1) and FAU_SAR.1(2) implement the requirements for the later
analysis of audit records by authorized administrators. FAU_STG.1 protects the audit re-
cords against modification. Identification of users (FIA_UID.1, FIA_UID.2) and user-subject
binding (FIA_USB.1) allows to record the originator of events as part of the audit records.
FMT_SMF.1 enables the management of the audit functionality.
O.AUTHENT_ADMIN requires that the TOE enforces the authentication of administrators
(with use of an external LDAP server). This is implemented by FIA_UID.2 requiring identifi-
cation and FIA_UAU.2 requiring authentication before any action other than authentication
can be performed on behalf of an administrator, and FIA_USB.1 providing for proper user-
subject binding. Passwords are stored in the initiator security attribute data base for each
administrator (FIA_ATD.1(2)). FIA_AFL.1(1) limits the attempts of unsuccessful authentica-
tion attempts to prevent password guessing. FMT_SMF.1 enables the management of the
authentication function.
O.ACC_ADM requires that administrators must be able to specify which objects may be ac-
cessed by which administrators or users (i.e. to manage according access control policy
rules). This is implemented by requiring appropriate access control policy rules in
FDP_ACF.1(2) and FDP_ACC.2(2), which in turn allow administrators to access information
– including access control policy rules – that is maintained by the TOE. In addition,
FMT_MTD.1 limits the ability to modify or delete user attributes to authorized administrators.
Roles are defined in FMT_SMR.1. FMT_SMF.1 allows management of access control policy
rules, which is restricted to be accessible only by administrators by FMT_MOF.1.
FMT_MSA.1(1), FMT_MSA.1(2) and FMT_MSA.3 refine the management of those rules.
FMT_MSA.2 provides for secure values. Implementation of the administrator access control
policy is supported by appropriate attributes as required by FIA_ATD.1(2), authentication of
administrators as required by FIA_UID.2 and user-subject binding as required by
FIA_USB.1. Access control contributes to the non-bypassability of the TSF (FPT_RVM.1).
O.SEC_COM requires the protection of communication links between separated parts of the
TOE. FTP_ITC.1 addresses this by demanding such a protected link between the TOE and
external entities (i.e. the LDAP server in the IT environment), while FPT_ITT.1 requires pro-
tected communication between different parts of the TOE when transferring TSF data. Inter-
nal TSF data consistency (FPT_TRC.1) is maintained via those secure channels. Protection
of communications is implemented by use of cryptographic functions, which is expressed by
FCS_CKM.1(1) (addressing the generation of session keys), FCS_CKM.1(2) (addressing
the generation of RSA key pairs), FCS_CKM.2(1) for exchange of RSA public keys,
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 78 2006-02-01
FCS_CKM.2(2) for the exchange of session keys, FCS_COP.1(1) for the digital signature
generation and verification and FCS_COP.1(2) for the encryption of the data using a sym-
metric algorithm. In addition FMT_MSA.2 ensures the selection of secure values for keys.
O.SOF required the enforcement of password policies for administrators and users. This is
achieved by a password policy defined in FIA_SOS.1 and supported by authentication fail-
ure handling in FIA_AFL.1(1) and FIA_AFL.1(2). Management of these mechanisms is pro-
vided in FMT_SMF.1.
The following section provides a mapping of security objectives for the TOE environment to
security functional requirements for the IT environment.
OE.OS_TIME requires the provision of a reliable time source by the operating system in the
IT environment. This is reflected in FPT_STM.1 for the operating systems for both Policy
Server and TAMOS RM. requiring them to provide such a time source.
OE.OS_CFG_PROT requires the protection of configuration files within the operating sys-
tem. For the Policy Server operating system, this is reflected in FMT_MTD.1 requiring to re-
strict the ability to modify one of those files (the configuration of audit events) to be accessi-
ble to authorized administrators only. Protection also requires the definition of roles in the
operating system to define those allowed to access and modify configuration files, which is
expressed in FMT_SMR.1 (the assignment of roles requires user identification, which is ex-
pressed in FIA_UID.1). In addition FMT_SMF.1 is included to address the requirement for
user and access management. FPT_SEP.1 for the operating system supports the access
protection. Vice versa, the requirements for the TAMOS RM underlying operating system in-
clude discretionary access control (since – as opposed to the Policy Server – here it is not
assumed that the resource manager is the only user of the system), implemented in
FDP_ACC.1 and FDP_ACF.1, and supported by FIA_ATD.1, FMT_MSA.1 and
FMT_MSA.3. Analog to the Policy Server operating system, FMT_MTD.1, FMT_SMF.1 and
FMT_SMR.1 are required.
OE.DS_ACCESS_CTRL requires authentication and access control mechanisms on the
LDAP server in order to prevent unauthorized access to directory entries and support au-
thentication of TOE administrators. This is reflected in the security functional requirements
FDP_ACC.1 and FDP_ACF.1 for the directory server requiring an access control system as
well as FDP_ETC.1 and FDP_ITC.1 addressing the import and export of user data (i. e. di-
rectory information). Identification and authentication are modeled in FIA_UAU.2 and
FIA_UID.2. Management of users and the access control function is expressed in
FMT_MSA.1, FMT_MSA.3 and FMT_SMF.1. To define a useful access control framework
the directory server should have a concept to define user roles, which is expressed with
FMT_SMR.1.
OE.FRIENDLY_DS requires a properly functioning LDAP server in order to provide authen-
tication decisions to the TOE for administrators, as expressed in FIA_UID.2 and FIA_UAU.2.
Note that the consistency aspects for replicas are not addressed by SFRs for the LDAP
server – this Security Target does not impose certain functional mechanisms to provide for
consistency between replicated information in the IT environment, but rather expects that
whatever mechanism the LDAP server implements is sound and well known to the adminis-
trators of the TOE. It is the responsibility of the administrators to ensure this (cf.
OE.REPLICAS).
OE.OS_AUTH requires identification and authentication of users of the TAMOS RM under-
lying operating system as a basis to implement the TOE’s access control mechanism for
users. This is reflected in the security functional requirements FIA_UAU.1 and FIA_UID.1
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 79 2006-02-01
and in FIA_USB.1 requiring proper user-subject binding.
OE.SEPARATION requires the provision of a separation mechanism to protect the TAMOS
RM application. This is modeled with the requirement FPT_SEP.1 to provide appropriate
domain separation.
8.2.3 Security Requirements Dependencies
The following table shows the fulfillment of dependencies imposed on security functional re-
quirements by Part 2 of the Common Criteria (the left column identifies the CC Part 2 com-
ponent, the middle column identifies the dependencies on that component drawn from CC
Part 2, and the right column illustrates how the dependency is fulfilled). Deviations between
requirements and fulfillment are explained subsequent to those tables. No additional de-
pendencies exist for the security functional requirements.
Dependencies within the EAL3 “package” selected for the security assurance requirements
have been considered by the authors of CC Part 3 and are not analyzed again in this Secu-
rity Target. The included component on flaw remediation, ALC_FLR.1, has no dependencies
on other requirements.
The security functional requirements in this Security Target do not introduce dependencies
on any security assurance requirement; neither do the security assurance requirements in
this Security Target introduce dependencies on any security functional requirement.
SFR Dependencies Fulfillment of dependencies
FAU_GEN.1 FPT_STM.1 FPT_STM.1 (environment)
FAU_GEN.3-TAMOS FPT_STM.1 FPT_STM.1 (environment)
FAU_GEN.2 FAU_GEN.1
FIA_UID.1
FAU_GEN.1, FAU_GEN.3-TAMOS
FIA_UID.1
FIA_UID.2
FAU_SAR.1 FAU_GEN.1 FAU_GEN.1, FAU_GEN.3-TAMOS
FAU_SEL.1 FAU_GEN.1
FMT_MTD.1
FAU_GEN.1
FMT_MTD.1 (environment)
FAU_STG.1 FAU_GEN.1 FAU_GEN.1
FCS_CKM.1(1) [FCS_CKM.2
or
FCS_COP.1]
FCS_CKM.4
FMT_MSA.2
FCS_CKM.2
FCS_COP.1(2)
FMT_MSA.2
(see note 1 below)
FCS_CKM.1(2) [FCS_CKM.2
or
FCS_COP.1]
FCS_CKM.4
FMT_MSA.2
FCS_CKM.2
FCS_COP.1(1)
FMT_MSA.2
(see note 1 below)
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 80 2006-02-01
SFR Dependencies Fulfillment of dependencies
FCS_CKM.2(1) [FDP_ITC.1
or
FCS_CKM.1]
FCS_CKM.4
FMT_MSA.2
FDP_ITC.1 (environment)
FCS_CKM.1(2)
FMT_MSA.2
(see note 1 below)
FCS_CKM.2(2) [FDP_ITC.1
or
FCS_CKM.1]
FCS_CKM.4
FMT_MSA.2
FCS_CKM.1(1)
FMT_MSA.2
(see note 1 below)
FCS_COP.1(1) [FDP_ITC.1
or
FCS_CKM.1]
FCS_CKM.4
FMT_MSA.2
FDP_ITC.1
FCS_CKM.1(2)
FMT_MSA.2
(see note 1 below)
FCS_COP.1(2) [FDP_ITC.1
or
FCS_CKM.1]
FCS_CKM.4
FMT_MSA.2
FCS_CKM.1(1)
FMT_MSA.2
(see note 1 below)
FDP_ACC.2(1) FDP_ACF.1 FDP_ACF.1(1)
FDP_ACC.2 (2) FDP_ACF.1 FDP_ACF.1 (2)
FDP_ACF.1 (1) FDP_ACC.1
FMT_MSA.3
FDP_ACC.2 (1)
FMT_MSA.3
FDP_ACF.1 (2) FDP_ACC.1
FMT_MSA.3
FDP_ACC.2 (2)
FMT_MSA.3
FIA_AFL.1 FIA_UAU.1 FIA_UAU.1
FIA_ATD.1 No dependencies No dependencies
FIA_SOS.1 No dependencies No dependencies
FIA_UAU.2 FIA_UID.1 FIA_UID.2
FIA_UAU.5 No dependencies No dependencies
FIA_UAU.6 No dependencies No dependencies
FIA_UID.1 No dependencies No dependencies
FIA_UID.2 No dependencies No dependencies
FIA_USB.1 FIA_ATD.1 FIA_ATD.1
FMT_MOF.1 FMT_SMF.1
FMT_SMR.1
FMT_SMF.1
FMT_SMR.1
FMT_MSA.1(1) [FDP_ACC.1 or
FDP_IFC.1]
FMT_SMF.1
FMT_SMR.1
FDP_ACC.2 (1)
FMT_SMF.1
FMT_SMR.1
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 81 2006-02-01
SFR Dependencies Fulfillment of dependencies
FMT_MSA.1(2) [FDP_ACC.1 or
FDP_IFC.1]
FMT_SMF.1
FMT_SMR.1
FDP_ACC.2 (2)
FMT_SMF.1
FMT_SMR.1
FMT_MSA.2 ADV_SPM.1
[FDP_ACC.1
or
FDP_IFC.1]
FMT_MSA.1
FMT_SMR.1
FDP_ACC.2(1)+(2)
FMT_MSA.1(1)+(2)
FMT_SMR.1
(see note 2 below)
FMT_MSA.3 FMT_MSA.1
FMT_SMR.1
FMT_MSA.1(1)+(2)
FMT_SMR.1
FMT_MTD.1 FMT_SMF.1
FMT_SMR.1
FMT_SMF.1
FMT_SMR.1
FMT_SMF.1 No dependencies No dependencies
FMT_SMR.1 FIA_UID.1 FIA_UID.1
FIA_UID.2
FPT_ITT.1 No dependencies No dependencies
FPT_RVM.1 No dependencies No dependencies
FPT_TRC.1 FPT_ITT.1 FPT_ITT.1
FTP_ITC.1 No dependencies No dependencies
Table 7: Dependency Analysis for TOE SFRs
Note 1: The dependency FCS_CKM.4 on the secure destruction of cryptographic keys is
applicable for the session keys used as well as the private RSA keys. Since those keys are
within the TOE and with the physical security of the TOE and the requirement not to have
any other application running on a machine of the TOE unless full separation between this
application and the TOE can be provided, it does not seem to be suitable to require a se-
cure destruction of session keys.
Note 2: FMT_MSA.2 has been included to address the dependencies from FCS_CKM.1,
FCS_CKM.2, FCS_COP.1 on this requirement. This addresses the use of “secure values”
for keys used for cryptographic operations. The symmetric keys used for secure communi-
cation between the TOE and external entities as well as for communication between differ-
ent parts of the TOE are generated automatically as defined by the SSL standard. The re-
quirement for an informal security policy model to satisfy the dependency is not resolved,
since the generation and distribution of the symmetric keys would anyhow not been ad-
dressed by such a model. The other dependencies are formally resolved, but since the
management of those session keys does not involve any user or administrator, none of the
security functional requirements listed actually addresses the key generation process. It is
therefore argued that the dependencies listed in FMT_MSA.2 are not applicable in this TOE.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 82 2006-02-01
SFR Dependencies Fulfillment of dependencies
LDAP Server
FDP_ACC.1 FDP_ACF.1 satisfied
FDP_ACF.1 FDP_ACC.1
FMT_MSA.3
satisfied
FDP_ETC.1 [FDP_ACC.1 or
FDP_IFC.1]
satisfied
FDP_ITC.1 [FDP_ACC.1 or
FDP_IFC.1]
FMT_MSA.3
satisfied
FIA_UAU.2 FIA_UID.1 Satisfied by FIA_UID2
FIA_UID.2 No dependencies No dependencies
FMT_MSA.1 [FDP_ACC.1 or
FDP_IFC.1]
FMT_SMF.1
FMT_SMR.1
Satisfied
FMT_MSA.3 FMT_MSA.1
FMT_SMR.1
Satisfied
FMT_SMF.1 No dependencies No dependencies
FMT_SMR.1 FIA_UID.1 Satisfied by FIA_UID.2
Policy Server System
FIA_UID.1 No dependencies No dependencies
FPT_STM.1 No dependencies No dependencies
FMT_MTD.1 FMT_SMR.1
FMT_SMF.1
Satisfied
FMT_SMF.1 No dependencies No dependencies
FMT_SMR.1 FIA_UID.1 Satisfied
FPT_SEP.1 No dependencies No dependencies
TAMOS RM System
FDP_ACC.1 FDP_ACF.1 Satisfied
FDP_ACF.1 FDP_ACC.1
FMT_MSA.3
Satisfied
FIA_ATD.1 No dependencies No dependencies
FIA_UAU.1 FIA_UID.1 Satisfied
FIA_UID.1 No dependencies No dependencies
FIA_USB.1 FIA_ATD.1 Satisfied
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 83 2006-02-01
SFR Dependencies Fulfillment of dependencies
FMT_MSA.1 [FDP_ACC.1 or
FDP_IFC.1]
FMT_SMF.1
FMT_SMR.1
Satisfied
FMT_MSA.3 FMT_MSA.1
FMT_SMR.1
Satisfied
FMT_MTD.1 FMT_SMF.1
FMT_SMR.1
Satisfied
FMT_SMF.1 No dependencies No dependencies
FMT_SMR.1 FIA_UID.1 Satisfied
FPT_SEP.1 No dependencies No dependencies
FPT_STM.1 No dependencies No dependencies
This table shows that all dependencies on security functional requirements are satisfied for
all the identified components in the IT environment.
8.2.4 Internal Consistency and Mutual Support
Chapter 8.2.2 has already shown how the security functional requirements work together to
implement the single objectives for the TOE and the IT environment. This chapter will elabo-
rate on the internal consistency and mutual support of the security functional requirements.
Further information can as well be found in the application notes to the security functional
requirements in chapter 5.
Internal Consistency and Mutual Support of security requirements for the TOE
The main goal of the TOE is to perform access control decisions for resources stored in the
TOE environment and to allow a sound management of the information that is necessary to
do so. The most vital information needed for access control decisions are the access control
policy rules, containing basically information on which target is allowed to be accessed by
whom. An appropriate access control security function policy, the Object-Space access
control policy is implemented by FDP_ACF.1(1). The enforcement of the access control
decisions made by the TOE is expressed by FDP_ACC.2(1). Another input to this access
control decision is the identity of the access request initiators. The TOE derives the identity
of resource manager users (FIA_UID.1) from the underlying operating system. Authentica-
tion is implemented by maintaining a data base of initiator security attributes, which is re-
flected by FIA_ATD.1(2) for users, and requiring the appropriate user-subject binding in
FIA_USB.1. For the password based authentication of users and administrators a minimum
strength of the passwords is required and defined in FIA_SOS.1. In addition the number of
consecutive unsuccessful authentication attempts is restricted as expressed in FIA_AFL.1
(2) for users. Since the policy database may be replicated, FPT_TRC.1 ensures the consis-
tency between the master policy database and the replica.
To allow for management of the access control policy rules used by the TOE for its access
control decisions, administrators of the TOE need to be able to execute appropriate man-
agement functionality. To clearly separate those duties (and the originators of appropriate
actions), a separation between user and administrator roles is introduced by FMT_SMR.1.
To protect the integrity of the TSF, including the TSF data, access control is required for the
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 84 2006-02-01
administrative access to the TOE. The same mechanisms are employed to implement this
access control as they are used to fulfill the access control decisions for the access re-
quests: access control policy rules define which administrator is allowed to access which
administrative functionality of the TOE. To prevent confusion, this is expressed in a separate
access control policy, the management access control policy, defined by FDP_ACF.1 (2).
Since it is not the intention of the TOE to leave the enforcement of access control decisions
with respect to the management of the TSF up to its environment, the authentication en-
forcement for administrators (FIA_UAU.2 and FIA_UID.2) as well as the enforcement of the
access control decisions (FDP_ACC.2 (2)) must be implemented by the TOE. For this rea-
son, the initiator security attribute data base contains as well the authentication secrets for
administrative users of the TOE (FIA_ATD.1(1)). With respect to the authentication of ad-
ministrators, authentication failure handling (FIA_AFL.1(1)) and a definition of minimum
constraints to the choice of authentication secrets (FIA_SOS.1) are required.
To detect possible attacks and to allow accounting for administrative actions, requirements
for the generation of audit data are included. Those comprise the definition of auditable
events and the outline of audit records (FAU_GEN.1, FAU_GEN.3-TAMOS) as well as the
association of auditable events with the identity of their originator, if the originator’s identity
is known (FAU_GEN.2). In order to comprehend the audited events, administrators must be
able to inspect the audit trails (FAU_SAR.1(1) and FAU_SAR.1(2)) and the audit information
has to be protected against unauthorized modifications (FAU_STG.1). To include the correct
time of an event in the audit records, appropriate information has to be delivered by the IT
environment (FPT_STM.1 for the underlying operating systems). The requirements
FAU_SEL.1(1) and FAU_SEL.1(2) and the requirements FMT_MTD.1 allow administrators
to specify which events are to be audited by the TOE.
Management functions are established by FMT_SMF.1 to allow the management of authen-
tication, communications security, audit and access control functionality. Such management
is restricted by FMT_MOF.1 to authorized administrators, while FMT_MSA.1(1) and
FMT_MSA.1(2) and FMT_MSA.3 impose the management access control policy on the
management actions.
Secure communication between different distributed parts of the TOE is required by
FPT_ITT.1 and also between the TOE and other trusted IT products (LDAP server, resource
managers) as required by FTP_ITC.1. In both cases this requires the use of cryptographic
functions as defined by the SSL protocol. While the generation and import of the RSA public
key pair is addressed in FCS_CKM.1(2), the generation of the symmetric session keys as
expressed by FCS_CKM.1(1), the distribution of RSA public key certificates as expressed
by FCS_CKM.2(2), the distribution of the symmetric session keys as expressed by
FCS_CKM.2(1) and the associated cryptographic operations for signing and signature veri-
fication (FCS_COP.1(1)) and symmetric encryption (FCS_COP.1(2)) are all addressed as
requirements for the TOE as well. The requirement for secure session keys is expressed
with FMT_MSA.2.
Bypass prevention for the security functions is achieved by introducing a requirement on
TSP enforcement in FPT_RVM.1.
Internal Consistency and Mutual Support of security requirements for the IT environ-
ment
The TOE makes use of the underlying operating systems for both Policy Server and re-
source manager to provide a reliable time stamp (as required by FPT_STM.1) and the ability
to manage the audit events of the TOE by editing the configuration file (as required by
FMT_MTD.1 and called out by FMT_SMF.1). Authorized roles need to be defined that are
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 85 2006-02-01
allowed to access the audit records as required by FMT_SMR.1 which depend on the cor-
rect identification of users as required by FIA_UID.1. This is supported by FPT_SEP.1 re-
quiring that the security functions of the underlying operating system maintain a domain for
their own execution protected from inference or tampering by untrusted subjects.
Additional requirements on the underlying operating system for the resource manager
exist: In order to protect the TOE resources in a multi-user environment, discretionary ac-
cess control is required as expressed in FDP_ACC.1, FDP_ACF.1, FIA_ATD.1,
FMT_MSA.1 and FMT_MSA.3. Also, the operating system has to authenticate users
(FIA_UAU.1, FIA_UID.1, FIA_USB.1) in order to support the access control mechanisms
implemented by the TOE.
The TOE uses an LDAP Server to store and maintain the user registry. To rely on the secu-
rity of this LDAP Server it has to be ensured that this server provides functions for user au-
thentication (as required by FIA_UAU.2 and FIA_UID.2) and access control (as required by
FDP_ACC.1 and FDP_ACF.1). In addition export and import of user data has to be per-
formed in accordance with the access control policy (as required by FDP_ETC.1 and
FDP_ITC.1). Management aspects are addressed by the security functional requirements
FMT_MSA.1, FMT_MSA.3, FMT_SMF.1 and FMT_SMR.1
8.2.5 Evaluation Assurance Level and Strength of Function
The evaluation assurance level (EAL) 3 was chosen as a medium level of assurance reflect-
ing the expected assurance requirements of commercial customers using the target of
evaluation (TOE) for the protection of data with a low or medium level of sensitivity. The
TOE is intended to provide a reasonable level of protection for this data comparable to the
protection provided by most commercial-off-the-shelf products. This is reflected as well in
the definition of the TOE environment in chapter 2 and the security objectives for the TOE in
chapter 4 of this Security Target.
The assurance level EAL3 was augmented with ALC_FLR.1 to address the flaw remediation
process employed by IBM. Since the evaluation methodology for ALC_FLR has been har-
monized and is also covered by the Mutual Recognition Arrangement, this was considered
to be a useful augmentation for the assurance level chosen.
In line with this medium level of assurance the functions provided by the TOE that are sub-
ject to probabilistic or permutational analysis (except for cryptographic algorithms and algo-
rithms related to the cryptographic functions) are claimed to have at least a medium strength
(SOF-medium). The function that is subject to strength of function analysis is
F.Authentication, which uses passwords. The certificate based authentication function and
the cryptographic algorithms used within F.Communication as well as the related key gen-
eration process are not subject to a strength of function analysis.
8.3 TOE Summary Specification Rationale
8.3.1 Security Functions Justification
The following table shows that the TOE security functions specified in the TOE summary
specification meet all security functional requirements for the TOE and work together to sat-
isfy the TOE security functional requirements.
SFR Security Functions from the TOE Summary Specification
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 86 2006-02-01
SFR Security Functions from the TOE Summary Specification
FAU_GEN.1 This requirement is addressed by the security function
F.Audit, which defines the events that the different parts of
the TOE are able to record, and the information contained in
audit records.
FAU_GEN.2 This requirement is addressed by the functions
F.Authentication, which requires users and administrators to
be authenticated and F.Audit which audits the identity of the
user that caused the event together with other relevant infor-
mation.
FAU_GEN.3-TAMOS This requirement is addressed by the security function
F.Audit, which defines the events that the different parts of
the TOE are able to record, and the information contained in
audit records.
FAU_SAR.1(1) and (2) This requirement is addressed by the function F.Audit which
provides tools to review audit records or, for the Policy Server,
audit logs that are human readable.
FAU_SEL.1(1) and (2) This requirement is addressed by F.Audit which allows defin-
ing the events that are to be audited in a configuration file.
Note that in theory the access control function of the TOE
could be used to control access to the audit configuration file,
but in most cases this would be left to the access control func-
tions of the underlying operating system.
FAU_STG.1 This requirement is addressed by F.Audit setting appropriate
access control permissions for audit logs that can be enforced
by the DAC of the underlying operating system.
FCS_CKM.1(1) This requirement is addressed by F.Communication which
defines that the SSL protocol is used to secure the communi-
cation between different parts of the TOE as well as between
the TOE and external entities. The cryptographic operations
themselves are described in the SSL standard.
FCS_CKM.1(2) This requirement is addressed by F.Communication which
defines that the administrator can generate RSA key pairs for
the use with the SSL v3 protocol. The TOE will only generate
key pairs for its own internal use. External entities authenticat-
ing to the TOE using a digital certificate are assumed to have
this authentication credential generated and protected se-
curely.
FCS_CKM.2(1) This requirement is addressed by F.Communication which
defines that the SSL protocol is used to secure the communi-
cation between different parts of the TOE as well as between
the TOE and external entities. The cryptographic operations
themselves are described in the SSL standard.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 87 2006-02-01
SFR Security Functions from the TOE Summary Specification
FCS_CKM.2(2) This requirement is addressed by F.Communication which
defines that the SSL protocol is used to secure the communi-
cation between different parts of the TOE as well as between
the TOE and external entities. The cryptographic operations
themselves are described in the SSL standard.
FCS_COP.1(1) This requirement is addressed by F.Communication which
defines that the SSL protocol is used to secure the communi-
cation between different parts of the TOE as well as between
the TOE and external entities. The cryptographic operations
themselves are described in the SSL standard.
FCS_COP.1(2) This requirement is addressed by F.Communication which
defines that the SSL protocol is used to secure the communi-
cation between different parts of the TOE as well as between
the TOE and external entities. The cryptographic operations
themselves are described in the SSL standard.
FDP_ACC.2(1) This requirement is addressed by F.Authorization where the
ACL and POP policies for resource objects are described.
FDP_ACC.2(2) This requirement is addressed by F.Authorization where the
access control policy for management objects is described.
FDP_ACF.1(1) This requirement is addressed by F.Authorization where the
ACL and POP policies for resource objects are described.
FDP_ACF.1(2) This requirement is addressed by F.Authorization where the
access control policy for management objects is described.
FIA_AFL.1(1) and (2) This requirement is described in F.Authentication which de-
scribes the limits on the number of successive authentication
failures allowed.
FIA_ATD.1(1) and (2) This requirement is described in F.Authentication where the
different user attributes are defined.
FIA_SOS.1 This requirement is described in F.Authentication where the
different possibilities for the password policy are defined,
while F.Management allows defining the policy.
FIA_UAU.2 This requirement is described in F.Authentication where the
authentication process for administrators is described.
FIA_UID.1 This requirement relates to F.Audit for the identification of
event generators and to F.Authorization where access con-
trol is enforced based on user identities.
FIA_UID.2 This requirement is described in F.Authentication where the
identification of administrators is described.
FIA_USB.1 This requirement is described in F.Authentication where the
binding of users / administrators to subjects is described.
User-subject binding contributes to F.Audit and
F.Authorization.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 88 2006-02-01
SFR Security Functions from the TOE Summary Specification
FMT_MOF.1 This requirement relates to F.Management, which defines the
management functionality for security functions.
FMT_MSA.1(1) This requirement is described in F.Authorization where the
different management objects and their management func-
tions are described and in F.Management where ACL and
POP management is described.
FMT_MSA.1(2) This requirement is described in F.Authorization where the
different management objects and their management func-
tions are described and in F.Management where ACL and
POP management is described.
FMT_MSA.2 This requirement relates to F.Communication, providing for
secure cryptographic keys.
FMT_MSA.3 This requirement relates to F.Management where the inheri-
tance policy for ACLs is described.
FMT_MTD.1 This requirement relates to F.Management where the man-
agement functions of administrators are described.
FMT_SMF.1 This requirement calls out the management functions de-
scribed in F.Management.
FMT_SMR.1 This requirement is described in F.Authorization where the
different roles are described.
FPT_ITT.1 This requirement is addressed by F.Communication which
defines that the SSL protocol is used to secure the communi-
cation between different parts of the TOE. The cryptographic
operations themselves are described in the SSL standard.
FPT_RVM.1 This requirement is addressed by the overall architecture of
the TOE. Every request from a client system is passed
through the authorization function F.Authorization.
FPT_TRC.1 This requirement is described in F.Authorization where the
replication mechanism for the policy database is described,
while F.Communication provides integrity of data exchanged
via communications links.
FTP_ITC.1 This requirement is addressed by F.Communication which
defines that the SSL protocol is used to secure the communi-
cation between the TOE and external entities. The crypto-
graphic operations themselves are described in the SSL stan-
dard.
Table 8: Mapping Security Functional Requirements to Security Functions
8.3.2 Justification that the Security Functions are mutually supportive
The main objective of the TOE is to provide access control for objects hosted on managed
resources.
As a result the TOE requires an authentication mechanism for administrators of the TOE,
which is defined in F.Authentication. Authentication of users is acquired from the underly-
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 89 2006-02-01
ing operating systems. Access control is divided into access control for user objects and ac-
cess control for management objects as defined in F.Authorization. The rules for adminis-
trators how to define and manage access control lists and protected object policies – the
two mechanisms the TOE uses for access control – as well as the rules for user and group
management are defined in F.Management.
To allow for individual accountability the TOE also includes an audit function as described
by F.Audit. This function can be used to trace the activities of users and administrators and
make them accountable for the actions they have performed.
To be able to enforce this policy the TOE needs to establish secure communication links be-
tween itself and external entities (i.e. the LDAP server hosting the user registry) as well as
between distributed parts of the TOE itself. This is accomplished by F.Communication de-
fining that the SSL protocol is used for all those communication links. This protects the TSF
data (including the protected objects) from unauthorized disclosure and modification when
transmitted over communication links. It also ensures that the different parts of the TOE it-
self authenticate themselves to each other when establishing a communication link. Man-
agement of the certificates used for protected communication is defined in F.Management.
As a result one can state:
• Protected resources can only be accessed by users authorized for this access.
• Management of the TOE functions is restricted to defined administrators.
• Bypassing the TOE security functions or attacking the communication between the TOE
and external entities or between distributed parts of the TOE is actively prohibited by the
TOE.
• Accountability is enforced by an audit trail capable to audit all administrator actions as
well as all access of users to protected resources.
This shows that the TOE security functions are mutually supportive.
8.4 PP Claims Rationale
No compliance with any existing Protection Profile is claimed.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 90 2006-02-01
9 Abbreviations
ACI Access Control Information
ACL Access Control List
ADF Access Control Decision Function
ADI Access Control Decision Information
AEF Access Control Enforcement Function
API Application Programming Interface
APP Authorization Protection Profile
CC Common Criteria, the name used historically for this multi-
part standard ISO/IEC 15408 in lieu of its official ISO name
of “Evaluation criteria for information technology security”
EAL Evaluation Assurance Level
PP Protection Profile
SF Security Function
SFP Security Function Policy
SOF Strength of Function
ST Security Target
TOE Target of Evaluation
TSC TSF Scope of Control
TSF TOE Security Functions
TSFI TSF Interface
TSP TOE Security Policy
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 91 2006-02-01
10 Glossary
Access Control Decision
Function (ADF)
A specialized function that makes access control decisions
by applying access control policy rules to an access re-
quest, ADI (of initiators, targets, access requests, or that
retained from prior decision), and the context in which the
access request is made.
Access Control Decision
Information (ADI)
The portion (possibly all) of the ACI made available to the
ADF in making a particular access control decision.
Access Control Enforce-
ment Function (AEF)
A specialized function that is part of the access path be-
tween an initiator and a target on each access request and
enforces the decision made by the ADF.
Access Control Information
(ACI)
Any information used for access control purposes, including
contextual information.
Access Control Policy The set of rules that define the conditions under which an
access may take place.
Access Control Policy
Rules
Security policy rules concerning the provision of the access
control service.
Access Request The operations and operands that form part of an at-
tempted access.
Assets Information or resources to be protected by the counter-
measures of a TOE.
Assignment The specification of an identified parameter in a compo-
nent.
Assurance Grounds for confidence that an entity meets its security
objectives.
Attack potential The perceived potential for success of an attack, should
an attack be launched, expressed in terms of an at-
tacker’s expertise, resources and motivation.
Augmentation The addition of one or more assurance component(s)
from Part 3 to an EAL or assurance package.
Authentication data Information used to verify the claimed identity of a user.
Authorized user A user who may, in accordance with the TSP, perform an
operation.
Class A grouping of families that share a common focus.
Component The smallest selectable set of elements that may be in-
cluded in a PP, an ST, or a package.
Connectivity The property of the TOE which allows interaction with IT
entities external to the TOE. This includes exchange of
data by wire or by wireless means, over any distance in
any environment or configuration.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 92 2006-02-01
Contextual Information Information about or derived from the context in which an
access request is made (e.g. time of day).
Dependency A relationship between requirements such that the re-
quirement that is depended upon must normally be satis-
fied for the other requirements to be able to meet their
objectives.
Element An indivisible security requirement.
Evaluation Assessment of a PP, an ST or a TOE, against defined
criteria.
Evaluation Assurance
Level (EAL)
A package consisting of assurance components from
Part 3 that represents a point on the CC predefined as-
surance scale.
Evaluation authority A body that implements the CC for a specific community
by means of an evaluation scheme and thereby sets the
standards and monitors the quality of evaluations con-
ducted by bodies within that community.
Evaluation scheme The administrative and regulatory framework under
which the CC is applied by an evaluation authority within
a specific community.
Extension The addition to an ST or PP of functional requirements
not contained in Part 2 and/ or assurance requirements
not contained in Part 3 of the CC.
External IT entity Any IT product or system, untrusted or trusted, outside of
the TOE that interacts with the TOE.
Family A grouping of components that share security objectives
but may differ in emphasis or rigor.
Formal Expressed in a restricted syntax language with defined
semantics based on well established mathematical con-
cepts.
Human user Any person who interacts with the TOE.
Identity A representation (e.g. a string) uniquely identifying an
authorized user, which can either be the full or abbrevi-
ated name of that user or a pseudonym.
Informal Expressed in natural language.
Initiator An entity (e.g. human user or computer-based entity) that
attempts to access other entities.
Internal communication
channel
A communication channel between separated parts of
TOE.
Internal TOE transfer Communicating data between separated parts of the
TOE.
Inter-TSF transfers Communicating data between the TOE and the security
functions of other trusted IT products.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 93 2006-02-01
IT environment See TOE environment.
Iteration The use of a component more than once with varying
operations.
Object An entity within the TSC that contains or receives infor-
mation and upon which subjects perform operations.
Organizational security
policies
One or more security rules, procedures, practices, or
guidelines imposed by an organization upon its opera-
tions.
Package A reusable set of either functional or assurance compo-
nents (e.g. an EAL), combined together to satisfy a set of
identified security objectives.
Product A package of IT software, firmware and/or hardware,
providing functionality designed for use or incorporation
within a multiplicity of systems.
Protection Profile (PP) An implementation-independent set of security require-
ments for a category of TOEs that meet specific con-
sumer needs.
Reference monitor The concept of an abstract machine that enforces TOE
access control policies.
Reference validation
mechanism
An implementation of the reference monitor concept that
possesses the following properties: it is tamperproof, al-
ways invoked, and simple enough to be subjected to
thorough analysis and testing.
Refinement The addition of details to a component.
Role A predefined set of rules establishing the allowed interac-
tions between a user and the TOE.
Secret Information that must be known only to authorised users
and/or the TSF in order to enforce a specific SFP.
Security attribute Information associated with subjects, users and/or ob-
jects that is used for the enforcement of the TSP.
Security Function (SF) A part or parts of the TOE that have to be relied upon for
enforcing a closely related subset of the rules from the
TSP.
Security Function Policy
(SFP)
The security policy enforced by an SF.
Security objective A statement of intent to counter identified threats and/or
to satisfy identified organization security policies and as-
sumptions.
tSecurity Target (ST) A set of security requirements and specifications to be
used as the basis for evaluation of an identified TOE.
Selection The specification of one or more items from a list in a
component.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 94 2006-02-01
Semiformal Expressed in a restricted syntax language with defined
semantics.
SOF-basic A level of the TOE strength of function where analysis
shows that the function provides adequate protection
against casual breach of TOE security by attackers pos-
sessing a low attack potential.
SOF-high A level of the TOE strength of function where analysis
shows that the function provides adequate protection
against deliberately planned or organized breach of TOE
security by attackers possessing a high attack potential.
SOF-medium A level of the TOE strength of function where analysis
shows that the function provides adequate protection
against straightforward or intentional breach of TOE se-
curity by attackers possessing a moderate attack poten-
tial.
Strength of Function (SOF) A qualification of a TOE security function expressing the
minimum efforts assumed necessary to defeat its ex-
pected security behavior by directly attacking its underly-
ing security mechanisms.
Subject An entity within the TSC that causes operations to be
performed.
System A specific IT installation, with a particular purpose and
operational environment.
Target An entity to which access may be attempted.
Target of Evaluation (TOE) An IT product or system and its associated administrator
and user guidance documentation that is the subject of
an evaluation.
TOE environment The term TOE environment depicts everything outside
the actual physical and logical TOE boundary. The TOE
may have certain expectations on the TOE environment.
Requirements to provide supportive functions for the
(technical) IT environment are expressed as security ob-
jectives for the environment and security functional re-
quirements in the ST, while objectives on security policy
support on the (organizational) non-IT environment are
expressed in security objectives for the environment.
TOE resource Anything useable or consumable in the TOE.
TOE Security Functions
(TSF)
A set consisting of all hardware, software, and firmware
of the TOE that must be relied upon for the correct en-
forcement of the TSP.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 95 2006-02-01
TOE Security Functions
Interface (TSFI)
A set of interfaces, whether interactive (man-machine
interface) or programmatic (application programming in-
terface), through which TOE resources are accessed,
mediated by the TSF, or information is obtained from the
TSF.
TOE Security Policy (TSP) A set of rules that regulate how assets are managed,
protected and distributed within a TOE.
TOE security policy model A structured representation of the security policy to be
enforced by the TOE.
Transfers outside TSF
control
Communicating data to entities not under control of the
TSF.
Trusted channel A means by which a TSF and a remote trusted IT prod-
uct can communicate with necessary confidence to sup-
port the TSP.
Trusted path A means by which a user and a TSF can communicate
with necessary confidence to support the TSP.
TSF data Data created by and for the TOE that might affect the
operation of the TOE.
TSF Scope of Control
(TSC)
The set of interactions that can occur with or within a
TOE and are subject to the rules of the TSP.
User Any entity (human user or external IT entity) outside the
TOE that interacts with the TOE.
User data Data created by and for the user, that does not affect the
operation of the TSF.
Tivoli Access Manager (TAMOS) 5.1 Security Target
Page 96 2006-02-01
11 References
[CAPP] Controlled Access Protection Profile, Version 1.d, National Security
Agency
[CC] Common Criteria for Information Technology Security Evaluation, Part 1:
Introduction and General Model; Version 2.1, August 1999
Common Criteria for Information Technology Security Evaluation, Part 2:
Security Functional Requirements; Version 2.1, August 1999
Common Criteria for Information Technology Security Evaluation, Part 3:
Security Assurance Requirements; Version 2.1, August 1999
[CEM] Common Methodology for Information Technology Security Evaluation
CEM-99/045 Part 2: Evaluation Methodology, Version 1.0, August 1999
[SSLv3] Alain O. Freier, Philip Karlton, Paul C. Kocher: The SSL Protocol, Version
3; IETF Memo, Internet Draft, November 1996
[AZNAPI] Open Group Technical Standard: Authorization (AZN) API, The Open
Group, January 2000
[ISO10181-3] ISO/IEC 10181-3: Information Technology – Open Systems Interconnec-
tion – Security frameworks for open systems: Access control framework,
1996
[AMBADM] Tivoli Access Manager for eBusiness Base Installation Guide, Version 5.1
[X.509] ITU-T RECOMMENDATION X.509 | ISO/IEC 9594-8: INFORMATION
TECHNOLOGY - OPEN SYSTEMS INTERCONNECTION - THE DIREC-
TORY: PUBLIC-KEY AND ATTRIBUTE CERTIFICATE FRAMEWORKS