UNCLASSIFIED

ACP 133(D)

COMMON DIRECTORY SERVICES

AND PROCEDURES

ACP 133(D)

COMBINED COMMUNICATIONS-ELECTRONICS
BOARD (CCEB)

JULY 2009

i Original
UNCLASSIFIED (Reverse Blank)
 UNCLASSIFIED
ACP 133(D)

FOREWORD
1. The Combined Communications-Electronics Board (CCEB) is comprised of the
five member nations, Australia, Canada, New Zealand, United Kingdom and United
States and is the Sponsoring Authority for all Allied Communications Publications
(ACPs). ACPs are raised and issued under common agreement between the member
nations.

2. ACP 133(D) COMMON DIRECTORY SERVICES AND PROCEDURES is an

UNCLASSIFIED CCEB publication. This ACP should be read in conjunction with the
ACP 133 Supp-1.

3. This publication contains Allied military information for official purposes only.

4. It is permitted to copy or make extracts from this publication.

5. This ACP is to be maintained and amended in accordance with the provisions of

the current version of ACP198.

iii Original
UNCLASSIFIED (Reverse Blank)
 UNCLASSIFIED
ACP 133(D)

THE COMBINED COMMUNICATION-ELECTRONICS BOARD

LETTER OF PROMULGATION

FOR ACP 133(D)

1. The purpose of this Combined Communication Electronics Board (CCEB) Letter
of Promulgation is to implement ACP 133(D) within the Armed Forces of the CCEB
Nations. ACP 133(D) COMMON DIRECTORY SERVICES AND PROCEDURES is
an UNCLASSIFIED publication developed for Allied use and, under the direction of the
CCEB Principals. It is promulgated for guidance, information, and use by the Armed
Forces and other users of military communications facilities.

2. ACP 133(D) is effective on receipt for CCEB Nations. NATO Military

Committee (NAMILCOM) will promulgate the effective status separately for NATO
nations and Strategic Commands.

EFFECTIVE STATUS

Publication Effective for Date Authority

ACP 133(D) CCEB On Receipt LOP/COMAG

3. This ACP will be reviewed periodically as directed by the CCEB Permanent

Secretary.

4. All proposed amendments to the publication are to be forwarded to the national

coordinating authorities of the CCEB or NAMILCOM.

For the CCEB Principals

Paul Foster
P. FOSTER
Major, CF
CCEB Permanent Secretary

v Original
UNCLASSIFIED (Reverse Blank)
 UNCLASSIFIED
ACP 133(D)

RECORD OF PAGE CHECKS

Date By Whom Checked Date By Whom Checked

Checked (Signature & Rank) Checked (Signature & Rank)

NOTE: This is a supplementary sheet.

It is not listed on the List of Effective Pages for this publication.

Original
UNCLASSIFIED (Reverse Blank)
 UNCLASSIFIED
ACP 133(D)

RECORD OF MESSAGE CORRECTIONS

Identification of Message
Correction and Reference Date Date Entered By Whom Entered
Reference Date Correction

vii Original
UNCLASSIFIED (Reverse Blank)
 UNCLASSIFIED
ACP 133(D)

TABLE OF CONTENTS
TITLE PAGE ....................................................................................................................... i
FOREWORD ..................................................................................................................... iii
THE COMBINED COMMUNICATION-ELECTRONICS BOARD LETTER OF
PROMULGATION..............................................................................................................v
RECORD OF MESSAGE CORRECTIONS.................................................................... vii
TABLE OF CONTENTS................................................................................................... ix
LISTS OF FIGURES AND TABLES .............................................................................. xii
CHAPTER 1 .................................................................................................................... 1-1
INTRODUCTION ........................................................................................................... 1-1
GENERAL AND SCOPE.................................................................................... 1-1
BACKGROUND ................................................................................................. 1-2
FUTURE EVOLUTION...................................................................................... 1-2
OVERVIEW OF ALLIED DIRECTORY SERVICES....................................... 1-2
CHAPTER 2 .................................................................................................................... 2-1
SYSTEM ARCHITECTURE .......................................................................................... 2-1
Section I - Directory System............................................................................................ 2-1
GENERAL........................................................................................................... 2-1
Section II - The Directory Information Base ................................................................... 2-2
ALLIED DIRECTORY SCHEMA...................................................................... 2-2
DIRECTORY ENTRIES FOR MESSAGING USERS....................................... 2-2
CONTENT RULES ............................................................................................. 2-2
DIRECTORY INFORMATION TREE............................................................... 2-3
SUBTREES.......................................................................................................... 2-3
Section III - User Services ............................................................................................... 2-5
USER ACCESS TO THE DIRECTORY ............................................................ 2-5
Section IV - Components................................................................................................. 2-7
GENERAL........................................................................................................... 2-7
DSAS ................................................................................................................... 2-8
BORDER DSAS .................................................................................................. 2-8
DUAS................................................................................................................... 2-9
Section V - Protocols ..................................................................................................... 2-11
GENERAL......................................................................................................... 2-11
DAP.................................................................................................................... 2-11
DSP .................................................................................................................... 2-11
DISP................................................................................................................... 2-12
DOP.................................................................................................................... 2-12
UNDERLYING PROTOCOLS ......................................................................... 2-12
LDAP ................................................................................................................. 2-12
DIRECTORY DATA REPRESENTATIONS .................................................. 2-13
LDIF................................................................................................................... 2-14
DSML ................................................................................................................ 2-14

ix Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

Section VI - Architectural Models................................................................................. 2-15

PROTOCOLS SUPPORTED ............................................................................ 2-15
SERVER ARCHITECTURES........................................................................... 2-16
DATA SUBSETTING, SEPARATION AND CHANGE MANAGEMENT... 2-18
USER ACCESS TO DATA............................................................................... 2-19
Section VII - Security of The Directory ........................................................................ 2-20
SECURITY MECHANISMS ............................................................................ 2-20
Section VIII - Management Of the Directory ................................................................ 2-21
MANAGEMENT ARCHITECTURE ............................................................... 2-21
MANAGEMENT PROTOCOLS ...................................................................... 2-21
TIME AND DATE STORAGE ......................................................................... 2-21
CHAPTER 3 .................................................................................................................... 3-1
DIRECTORY INFORMATION POLICIES AND PROCEDURES .............................. 3-1
Section I - Schema Definition.......................................................................................... 3-1
SCHEMA OVERVIEW....................................................................................... 3-1
COMMON CONTENT ....................................................................................... 3-1
DIRECTORY ENTRIES ..................................................................................... 3-2
DIRECTORY NAMES........................................................................................ 3-2
ORGANIZATIONAL ROLES ............................................................................ 3-4
CERTIFICATION AUTHORITY FUNCTION.................................................. 3-5
ACP 127 USERS ................................................................................................. 3-5
USE OF THE SEEALSO ATTRIBUTE ............................................................. 3-6
Section II - Entry Population and Usage.......................................................................... 3-7
Section III - Registration.................................................................................................. 3-9
REGISTRATION REQUIREMENTS................................................................. 3-9
TECHNICAL OBJECT IDENTIFIER ................................................................ 3-9
DIRECTORY DISTINGUISHED NAMES ........................................................ 3-9
GENERAL REGISTRATION REQUIREMENTS........................................... 3-10
Section IV - Shadowing Policies ................................................................................... 3-11
Section V - Chaining Policies ........................................................................................ 3-12
Section VI - Directory System Performance ................................................................. 3-13
GENERAL......................................................................................................... 3-13
EASE OF USE................................................................................................... 3-13
ROBUSTNESS .................................................................................................. 3-13
AVAILABILITY ............................................................................................... 3-13
SERVICE RESTORATION .............................................................................. 3-13
SPEED OF RESPONSE .................................................................................... 3-13
HUMAN INTERFACES ................................................................................... 3-14
OTHER APPLICATIONS................................................................................. 3-14
PERFORMANCE CHARACTERISTICS ........................................................ 3-14
DUA CACHING GUIDELINES....................................................................... 3-16
CHAPTER 4 .................................................................................................................... 4-1
DIRECTORY SECURITY POLICIES AND PROCEDURES....................................... 4-1
Section I - Security........................................................................................................... 4-1

x Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

SECURITY SERVICES ...................................................................................... 4-1

AUTHENTICATION .......................................................................................... 4-2
ACCESS CONTROL - GENERAL..................................................................... 4-3
BASIC ACCESS CONTROL (BAC).................................................................. 4-4
RULE-BASED ACCESS CONTROL (RBAC) .................................................. 4-5
ACCESS CONTROL DECISION FUNCTION.................................................. 4-6
KEY MANAGEMENT ....................................................................................... 4-8
CONFIDENTIALITY.......................................................................................... 4-8
LABELING.......................................................................................................... 4-9
GENERAL........................................................................................................... 4-9
Section II - Accountability/Auditing ............................................................................. 4-12
DATA PROTECTION....................................................................................... 4-12
CHAPTER 5 .................................................................................................................... 5-1
DIRECTORY MANAGEMENT POLICIES AND PROCEDURES.............................. 5-1
SCOPE ................................................................................................................. 5-1
MANDATED FUNCTIONALITY ..................................................................... 5-1
DESIRABLE ADDITIONAL FUNCTIONALITY ............................................ 5-2
EVENT LOGS ..................................................................................................... 5-2
SERVICE LEVEL AGREEMENTS (SLA) ........................................................ 5-3
CHAPTER 6 .................................................................................................................... 6-1
SCHEMA......................................................................................................................... 6-1
Section I - Concepts ......................................................................................................... 6-1
GENERAL........................................................................................................... 6-1
Section II - Common Structural Object Classes .............................................................. 6-2
COMMON STRUCTURAL OBJECT CLASSES .............................................. 6-2
DIRECTORY BASE STRUCTURAL OBJECT CLASSES .............................. 6-2
OTHER STANDARD STRUCTURAL OBJECT CLASSES ............................ 6-3
DIRECTORY STANDARD OBJECT CLASS DESCRIPTIONS ..................... 6-4
Section III - Directory System Schema ........................................................................... 6-6
GENERAL........................................................................................................... 6-6
STANDARD OPERATIONAL ATTRIBUTES ................................................. 6-7
DIRECTORY OPERATIONAL ATTRIBUTES ................................................ 6-7
DSA SPECIFIC ENTRY (DSE) OPERATIONAL ATTRIBUTES ................... 6-8
RULES FOR DIT SCHEMA MANAGEMENT................................................. 6-9
REFERENCES ...........................................................................................................REF-1
GLOSSARY ........................................................................................................ Glossary-1
Definitions............................................................................................................ Glossary-1
ACRONYMS....................................................................................................... Glossary-3
LIST OF EFFECTIVE PAGES .................................................................................. LEP-1

xi Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

LIST OF FIGURES

Figure 1-1 - Overview of the Allied Directory ................................................................ 1-3

Figure 1-2 - The Directory Model ................................................................................... 1-5
Figure 2-1 - Directory User Access ................................................................................. 2-5
Figure 2-2 - Example Allied directory Configuration ..................................................... 2-7
Figure 2-3 – Example Hub and Spoke Architecture...................................................... 2-17
Figure 2-4 – Example Mesh Replicated Architecture.................................................... 2-18
Figure 2-5 – Model for Management of the Directory .................................................. 2-21
Figure 3-1 – Methods of ACP 127 Interworking............................................................. 3-8
Figure 4-1 – Diagram of ACDF Required for Basic Access Control .............................. 4-7
Figure 4-2 – Diagram of ACDF Required for Rule-based and Basic Access Control .... 4-8

LIST OF TABLES

Table 3-1 – Population of Directory Entries for Applications......................................... 3-8

Table 6-1 - DSE Types and Their Purpose .................................................................... 6-11

xii Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

CHAPTER 1

INTRODUCTION
GENERAL AND SCOPE

101. The function of this document, Allied Communication Publication (ACP) 133, is
to define the Directory services, architecture(s), protocols, schema, policies, and
procedures to support Allied communications, including Military Message Handling
System (MMHS) services based on ACP 123, in both the strategic and tactical
environments. The Directory services are based on the International Telecommunication
Union Telecommunication Standardization Sector (ITU-T) X.500 Series of
Recommendations and the International Organization for Standardization (ISO) /
International Electrotechnical Commission (IEC) 9594. These Directory specifications
will be referred to as X.500 in this document. Note that familiarity with X.500 is
assumed.

102. The Allied Directory Services defined in this document are based on the X.500
Directory recommendations (exact documents and version numbers listed in References
on page REF-1). It is expected that an evolutionary period will be necessary for existing
Directory Services to become ACP 133-compliant. In this sense, ACP 133 is viewed as a
“target”. The manner, means, and duration of such evolution are outside the scope of
ACP 133.

103. This ACP applies to communication among the Allied Directory domains and
within a domain for combined operations. It defines a common Directory schema which
shall be supported by all Allies for international and combined operations. It offers
support for Internet mail users and transitional support for ACP 127/Joint Army, Navy,
Air Force Procedure (JANAP) 128. The Directory has the potential to support different
views of directory information such as white pages and yellow pages services.

104. Local interfaces and requirements, such as the specifics of terminal display and
local caching, are part of this publication where required to ensure interoperability.
ACP 133 includes requirements for which directory information must be displayed to the
user, but the format of the display is outside the scope of this document.

105. The third version of ACP 133 defines the services, schema, and protocols required
of X.500 Directory System Agents (DSAs) and Directory User Agents (DUAs) to support
electronic mail (e-mail), S/MIME, Message Handling System (MHS), MMHS, ACP 127
interworking and traditional communications. It also identifies security mechanisms that
meet the security requirements for strong authentication, confidentiality, integrity,
availability, and privilege/label management. As national systems and products mature,
this document will be expanded to include more procedural guidance for managing the
directory, support for other applications, and additional guidance for operation of tactical,
mobile and deployed directories.

1-1 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

106. In order to maximize the number of products supporting ACP 133, the schema
definition has been split into a core schema, to which all products must conform, plus
optional schema sections relating to PKI Infrastructures and legacy (ACP 127 /
JANAP 128) messaging. In addition, Lightweight Directory Access Protocol (LDAP)
has been added as an alternative Directory Access Protocol (DAP), thus reflecting its
almost universal adoption over X.500 DAP for general user access to the Directory.
Where possible, to maximize compatibility with existing COTS Directory Products, the
ACP 133 schema has been redefined to utilize standard attribute syntaxes in preference to
proprietary ones used in earlier versions of this document.

BACKGROUND

107. This ACP was originally written and coordinated by the Combined
Communications Electronics Board (CCEB) with the Allied Message Handling (AMH)
International Subject Matter Experts (ISME) working group. This group was organized
to develop a common messaging strategy that can be deployed to facilitate
interoperability among the Allies for military message traffic. Part of this task, and the
subject of this ACP 133, was to develop a directory service that could provide access to
information needed for messaging. An ACP 133 Task Force was formed to develop
Directory requirements and this ACP.

108. To ensure interoperability with North Atlantic Treaty Organization (NATO)

members, ACP 133 was developed in coordination with the NATO Tri-Service Group of
Communications and Electronics (TSGCE). Rather than developing a separate NATO
document, the intention is for this document to satisfy the requirements for military
messaging with NATO and United Nations forces. To this end, this and future editions
of this document will be approved both by NATO and CCEB Directory Services
Working Groups (DSWGs) on behalf of their respective organizations.

109. Responsibility for the maintenance of this ACP currently rests with the CCEB
DSWG.

FUTURE EVOLUTION

110. This ACP is based on civilian international standards in order to take advantage of
the availability of Commercial Off-The-Shelf (COTS) directory products. As a result, the
CCEB and NATO DSWGs should monitor the future development of the international
standards and the resultant products. As new capabilities are standardized those that are
found to be useful and appropriate should be added to ACP 133. In order to maintain
consistent directory service among the Allies, new versions of this ACP will be
developed with formal review and coordination.

OVERVIEW OF ALLIED DIRECTORY SERVICES

111. The Allied Directory is the combination of the parts of the national directories and
those Combined Task Force (CTF) directories, when they exist, that are to be shared with
the Allies. For example, specific unique directory requirements must be satisfied to

1-2 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

support operations which would result from dynamic military operations. Thus, it is
envisioned that the Allied Directory will consist of relatively stable, shared national and
combined domains, as well as periodic dynamic combined domains to satisfy specific
operations involving coalitions of national military forces and organizations, such as
NATO. An overview of the Allied Directory is shown in Figure 1-1. It should be noted
that whilst this section describes an X.500 implementation of the Allied Directory, it does
not preclude the use of other technologies such as LDAP Servers.

112. A third class of directory making up the Allied Directory belong to organizations,
which could be permanent collectives (such as NATO) or functionally based
organizations requiring their own directory, such as a coalition collaborative tool
management organization. This latter organization could manage the membership of
collaboration services (such as “chat rooms”) on behalf of the user nations. Directory
entries held by it could be chat room names, with membership being defined by pointers
to entries in national directories.

Figure 1-1 - Overview of the Allied Directory

113. The information accessible using the Allied Directory System is contained in the
Allied Directory Information Base (DIB). The information published in the Allied
Directory DIB is provided to support Allied communications, including MMHS services
based on ACP 123, in both the strategic and tactical environments. Besides the
information used by the messaging application, the Allied Directory System supports the
storage of certificates needed for secure messaging (e.g., ACP 120) and for other secure

1-3 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

applications such as Electronic Data Interchange (EDI). The Allied Directory DIB also
contains information for managing the components of the Allied communications system.

114. A Directory Management Domain (DMD) is composed of all of the directory

components, policies, and information of an organization for the purposes of
management. In the Allied Directory System there are three types of directory domains,
as illustrated in Figure 1-1, viz national domains, organizational domains and Combined
Task Force (CTF) domains. A national domain includes the information, policy, and
components needed to govern a specific nation’s directory services. The union of all
information shared is said to comprise a single logical DIB.

115. A CTF domain is a subset of the Allied Directory that is provided by two or more
Allies and includes unique mission-related information, policy, and components. The
combined domain is owned, operated and administered by a multi-national military unit.
The commander of the CTF establishes the rules and procedures for its domain. No
information and components are supplied or maintained by the CCEB. Rather, this ACP
defines mechanisms for sharing information and interconnection of national assets to
support combined operations. Note that, in this ACP, the significance of the term
“combined task force” is very broad and should not be confused with specific “task
force” designations already in use by various organizations such as Naval Task Force,
defined by AUSCANZUKUS.

116. The Directory is composed of one or more DSAs that are the repositories for
some portion of the DIB. The DIB contains user information and operational information
for use by the Directory system. Each user of the Directory, whether a person or an
application, uses a DUA to access the Directory. The Directory schema contains the
rules governing the contents of the DIB. Within a Nation, a specialized Directory, known
as a “Border” DSA, will normally be used to provide separation between the Nation’s
internal domains and the Allied Directory domain. The Border DSA will normally
contain that subset of the Nation’s DIT which it is prepared to share with other Nations,
thus insulating itself and protecting against accidental or malicious extraction of National
directory information.

117. In a native X.500 environment, DUAs and DSAs communicate with each other by
using the Directory Access Protocol (DAP), whilst DSAs communicate with each other
using the Directory System Protocol (DSP), the Directory Information Shadowing
Protocol (DISP) or the Directory Operational Binding Management Protocol (DOP).
DSP is used by DSAs to “chain” requests from users when the originating or “home”
DSA of the user does not have the requested information. DISP is used in the process of
replicating information among DSAs. DOP is used to perform the management aspects
of replication necessary for DISP and to maintain the knowledge and access control,
collective attributes, and other administrative information. These components and
protocols are pictured in Figure 1-2.

118. There are many different architectural models which may be adopted to
implement a specific instance of an Allied Directory, and this ACP is not intended to be

1-4 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

prescriptive as to how this should be achieved. The two most popular architectures
which have been considered are:

a. Hub and Spoke: In this scenario, a central Hub Directory acts as a routing
point for all partcipants, allowing them to share their information once to
the Hub, whilst receiving all other participants’ information back from the
Hub; and

b. Mesh: In this scenario, all participants communicate with all others to

send and receive a copy of that partners data.

119. In some architectures, a copy of all other nations’ data is held locally, whilst in
others, the DSP protocol is used to get required information from a remote server on
demand from users. There is no single architecture which is better than any other, the
choice should be based on the particular needs and characteristics of the Directory service
required by its users and the underlying network capabilities available.

Figure 1-2 - The Directory Model

120. Where non-X.500 components comprise part of the directory environment, other
protocols such as LDAP (Lightweight Directory Access Protocol) may be used. In
particular, LDAP will often be preferred over DAP as a more efficient protocol for user
access to the directory. It may also be used in place of X.500 DISP for replication of
directory data to and from a National Border Directory and the Allied Directory. Other
non-X.500 protocols and mechanisms also exist such as LDIF (Lightweight Directory
Interchange Format), which allows directory data to be exchanged as text files and is
already used for data interchange within CCEB and NATO.

121. The logical arrangement of the structure of the DIB is called the Directory
Information Tree (DIT). Different parts of the DIT will be managed by different
organizations. To accomplish this, the DIT can be divided into subtrees called
administrative areas. Policies concerning access control, schema, and collective
attributes, which are explained later in this document, may then be formulated for
particular subtrees.

1-5 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

122. The Allied Directory schema contains the rules governing the contents of the
DIB. The schema includes a set of definitions for DIT Structure Rules, Object Classes,
Attribute Types and Matching Rules. The Allied Directory Schema is based to the extent
possible on definitions in the ITU-T X.400 and X.500 Series of Recommendations and
other applicable standards for object classes, attribute types, and matching rules. Where
necessary, ACP 133 defines these elements or imports definitions from other sources. In
this document, schema elements are highlighted by bold italics.

123. Because of the almost universal use of LDAP as the user access protocol of
choice, the schema definition has been augmented with corresponding LDAP definitions
of X.500 schema elements. However, it is not intended at this time to enhance the
schema to provide all information necessary to allow full implementation of LDAP
servers to replace X.500 servers. If this becomes a requirement in future, the schema can
be augmented to add this information.

124. In addition to the user information which is controlled by the Allied Directory
Schema, an X.500 implementation of the Allied Directory System can contain directory
administrative and operational information. This system information is governed by the
Allied Directory System Schema which is a set of definitions and constraints concerning
the information that the Allied Directory System itself needs to know in order to operate
correctly. This information is specified in terms of subentries and operational attributes.
Subentries contain information relevant to a particular subtree of the DIT, and contain
operational attributes. Also, user entries may contain operational attributes, such as, the
last time the entry was modified.

125. Whilst X.500 and other directory standards and recommendations describe the
complete directory service model, and this and subsequent chapters describe how the
complete Allied directory may be built, the key requirement of ACP 133 is how the
nations and organizations making up the Allied Directory service actually share their
information. Thus nations may extend schemas and change their system to meet local
needs and policies, but how they share this information with other nations must conform
to the schema and rules (i.e., only entries, objects and attributes defined in this document
may be shared using mechanisms defined here). This is to allow maximum scope to
nations to build directories which meet their needs, whilst still ensuring interoperability
in the Allied Directory arena.

1-6 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

CHAPTER 2

SYSTEM ARCHITECTURE

Section I - Directory System

GENERAL

201. The Allied Directory is a set of interconnected systems, each supporting a

different subset of the total information base. The information that is accessible by users
of the Allied Directory is the same for each user, subject to access controls; that is, the
Allied Directory service has the appearance of a single information base. The Allied
Directory system comprises:

a. The information supplied by each Nation or Organization;

b. The services offered to the user to access the information;

c. The systems in which the information is housed or used i.e., the directory
physical architecture;

d. The protocols used for exchange of the information among the

components;

e. The architectures which may be employed to implement the system;

f. The means of protecting the information and components against a variety

of threats; and

g. The means of managing the information and components.

202. Whilst this and the following chapters consider the directory system in general,
much of this is beyond the scope of ACP 133, which is primarily concerned with the
sharing of information between nations and authorized organizations. It is anticipated
that nations will extend schemas beyond those defined in this document and will provide
services to users and administrators which may not always conform to the services
described here, dependent upon local policies and rules. However, when nations or
organizations need to share information through the Allied Directory, rules for
interoperability (i.e., what may be shared and how) must be adhered to.

2-1 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

Section II - The Directory Information Base

ALLIED DIRECTORY SCHEMA

203. The Allied Directory Schema encompasses the directory entry types, object
classes, attributes, matching rules, name forms and structure rules that are necessary for
specifying the information that is stored in the Allied Directory System. Components of
the Allied Directory System shall implement all of the standard object classes, attributes,
and name forms defined in X.501, X.509, X.520, X.521 and X.402, as specified in ACP
133 Supp-1. The Allied Directory Schema, called Common Content, employs the
standard schema elements and also includes object classes, attributes and name forms
defined in this ACP especially to meet Allied requirements. The Allied Directory
Schema is described in chapter 6 and specified fully in ACP 133 Supp-1.

DIRECTORY ENTRIES FOR MESSAGING USERS

204. One purpose of the Allied Directory is to provide access to stored information
about organizations and individuals in various Allied domains to enable them to
exchange messages i.e., to be users of the message exchange services defined in
ACP 123. The stored information is the DIB in which each entry represents a user or
group of users. Three types of entries are defined, corresponding to the organizational
unit, organizational role, and organizational person (i.e., an individual) categories of
messaging users. A fourth type of entry, address list, is defined for representing groups
of users.

CONTENT RULES

205. Content rules, which are part of the X.500 schema definition, are used for two
purposes:

a. A content rule can be used to define one or more entry types with a base
structural object class by adding auxiliary object classes and adding (or
deleting) attributes without creating a new object class; and

b. The X.500 directory standard requires the use of a content rule to allow
the application of collective attributes to an entry type, since none of the
defined object classes are allowed to contain collective attributes.

206. Recent experience with interoperability testing between Nations using different
directory products has identified significant issues relating to the use of content rules. In
view of this, content rules have been removed from the ACP 133 Common Content
schema (ACP 133 Supp-1), for the following reasons:

a. Content Rules are not supported by some COTS Directory Products. Of

those COTS products that do support them, some do not always
implement them correctly, leading to incompatibility issues;

2-2 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

b. Collective attributes are no longer included with the ACP 133 Schema;
and

c. DISP Replication testing has identified that the key requirement for
successful replication is use of a common schema, exactly matching
Object Classes and attributes to entries. Modification to the contents of
entries beyond that explicitly defined by the associated Object Classes is a
major cause of replication failure. Thus ACP 133 Supp-1 contains Object
Class definitions which must be fully conformed to for data sharing
between Nations and Coalitions.

207. The removal of content rules from ACP 133 SUPP-1 does not preclude their use
internally within a specific directory product. However, when attempting
interoperability, strict adherence to ACP 133 SUPP-1 is required.

DIRECTORY INFORMATION TREE

208. Entries in the Allied Directory are arranged in the form of an inverted tree, called
the DIT, where the vertices represent the entries. Each entry adds the value of one or
more attributes. The ordered list of the values of the branches through the tree to a user
entry is the Distinguished Name (DN) for the entry. The entries highest in the Allied
Directory tree represent countries and international/multinational organizations (such as
NATO), those in the middle represent organizations and localities, and those at the
bottom represent individuals, application processes, address lists, etc.

SUBTREES

209. The Allied Directory DIT is composed of a number of subtrees obtained from
participating Nations, Allies and Coalitions. Nations will normally provide a national
subtree whose most superior element is a country entry (as defined by X.521),
immediately below the root 1 . Additional subtrees may be provided, again normally
immediately below the root, by associated organizations (such as NATO), by Coalition
members with responsibility for directory management within the Coalition and even by
Nations which have already provided their country entry. These additional subtrees will
be headed by a superior element comprising either an organization or a locality entry
(again both as defined in X.521).

210. The arrangement of the levels of the DIT below a top-level entry, and the values
of the entries, are a matter of national or coalition policy and are outside the scope of this
ACP as long as the structure rules defined by this ACP are not violated when entries are
shared in the Allied Directory.

1The root is the notional top of the DIT, below which top-level entries are created. Only
certain Object Classes may be held immediately below the root.

2-3 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

211. Typically, below the country entry of a Nation is one of the subtrees that include
the armed forces of the Ally, e.g., Department of Defense for the U.S. The armed forces
are usually represented by an organization or organizationalUnit. Below the armed
forces level, each Nation will define the subtrees that contain the information needed to
represent its forces, including services, agencies, and commands. The commands may
also include the CTFs that are led by the Nation.

2-4 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

Section III - User Services

USER ACCESS TO THE DIRECTORY

212. ACP 123 defines message handling services offered to the user in terms of
Elements of Service (EoS) according to the definitions in the X.400 Recommendations.
The X.500 Recommendations do not define services offered to the users in this way. In
this document, the services that are offered to the Directory user are referred to by the
term “user services”. Some user services are described as optional, that is, they are
available to the user only if they are offered by the Allied Directory System. The user
shall be able to select the appropriate user services for interrogation, modification and
administration of the Allied Directory.

213. Generally, the user services are employed to deal with “directory user
information”, i.e., the information in the directory about the entities represented by the
entries. Administration is a special case of directory usage where access is also necessary
to the “directory system information”, which is the information in the entries and
subentries concerning the operation of the Directory itself, such as Access Control
Information (ACI). Interrogation, modification, and administration usages of the
directory are illustrated in Figure 2-1. Although the figure shows human users, a
directory user may be an application process, such as an MMHS User Agent (UA).

Figure 2-1 - Directory User Access

2-5 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

214. The Allied Directory System provides all standard X.500 directory user services,
which correspond to the formal operations specified for access to a directory system.
However, the Allied Directory System limits the use of some services by some users. For
example, only authorized personnel may be allowed to employ the user services that
create new entries in the Allied Directory.

215. User authentication is also required by the Allied Directory Service, but in a local
environment, this will be defined by national policy. Additional authentication
requirements and details are addressed in paragraph 402. In the national domain, read-
only access to local information (including copies of other nation’s data) may be
provided in “anonymous” mode, in which no authentication information is required from
the user.

216. For every user service, the results or errors from each request shall be provided,
either in textual form to a human user or through a result code to an application.

217. The preferred protocol used by many nations for directory access is LDAP, rather
than the DAP protocol defined for directory access in X.500. LDAP (Lightweight
Directory Access Protocol) was originally developed for smaller user access devices
(e.g., PCs) when computing power and memory was much more limited, and employs
simpler and less memory and processor intensive protocols, with fewer, simpler
operations available plus the use of text strings for data transfer in all but the most
complex situations. Although the arguments for use of LDAP to match available
computing power are not longer applicable, the directory world, and CCEB/NATO
nations, has almost entirely adopted LDAP as the user access protocol of choice. In order
to use it, national directories need to provide an LDAP service, either built-in directly to a
DSA or as a separate LDAP server, which accepts LDAP requests and translates these to
DAP before relaying them on to the DSA.

2-6 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

Section IV - Components
GENERAL

218. The components of the Allied Directory System are:

a. Directory System Agent (DSA): A DSA is used to hold directory

information within a Nation or within the Allied Domain. The DSA may
hold a copy of all information, or it may participate with other DSAs
within the Domain to share the complete DIB;

b. Border DSAs: A Border DSA provides a presence into the Allied

Domain for accessing that part of the National DIB which it is prepared to
share with other nations. It may also obtain copies of other Nations data
and present this back into the Nation Domain. The Border DSA ensures
physical data separation, thus protecting local DSAs from external attack.
How data is shared with the Border DSA and its actual location (e.g.,
beyond/within national firewalls etc.) is an implementation choice; and
c. Directory User Agent (DUA): A DUA is an application process which
acts on behalf of a user or application, and provides an interface into the
directory. DUAs are usually hosted within the National domain, except
for Administrative DUAs required to manage the Allied Directory. DUAs
will use the DAP or LDAP protocol to access a DSA.

An example of interconnecting these components is illustrated in Figure 2-4.

Figure 2-2 - Example Allied directory Configuration

2-7 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

219. This section applies to both national and combined domains described in
paragraph 111. The DSAs within a CTF domain are termed “National” and “Border” in a
manner analogous to a national domain. That is, a National DSA in a CTF domain is
only connected to DSAs within the domain and connections to other domains are made
by Border DSAs.

DSAS

220. DSAs collectively hold the Allied DIB and interact with one another to make the
entire DIB accessible to the directory users. The directory system is comprised of DSAs
that interact with one another to perform the directory services described above. The
DSAs interact with DUAs to get user requests and provide the results from processing the
requests.

221. Within each DMD, the distribution of directory information among multiple
DSAs is a national/combined task force matter, subject to the quality of service,
management and security provisions of this ACP.

222. The Allied Directory System is composed of a two-tier hierarchy of DSAs:

Border DSAs and National DSAs. An optional third tier may be present (dependent upon
selected architecture), which are Allied DSAs, which provide consolidation services
within the central Allied Domain.

223. The contents of National DSAs are a national matter, except that a common
definition of National DSA contents is necessary for interoperability of assets from
different nations in CTF domains. The contents of the Border DSAs are the information
the ally makes available in the Allied Directory System. Which
Services/agencies/commands, entries or attributes from the national directory service are
included in the Allied Directory System is a national or CTF matter. A combination of
Directory access controls and other separation mechanisms such as entry subsetting may
be used to effect the segregation of domain-specific and shared information.

BORDER DSAS

224. A Border DSA is a logical or physical DSA that has been designated to provide
the primary international interface for a nation’s or CTF’s directory system. The
implementation of an instance of a Border DSA may be a specific or separate component
or a logical partition of the information, or even a process which subsets the information
into a non-directory form which can be shared bilaterally with other nations (e.g., a CSV
or LDIF file). Where Border DSAs actually exist, they may be interconnected to enable
the sharing of directory information across DMDs. Within a CTF, DSAs from the
participating Allies shall interoperate in accordance with this ACP.

225. A Border DSA shall perform many functions that ordinary DSAs within a nation
or CTF need not support. One of the major functions of a Border DSA is to provide the
portion of the national/task force DIB available for access in the Allied Directory System.
Thus, some portions of the national DIB may be unavailable to the Allied Directory

2-8 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

System. Also, a different security policy may apply to Border DSAs than to national
DSAs. How these subsetting and security requirements are met is implementation
independent.

226. The process for resolving directory queries within a particular national directory
domain is beyond the scope of ACP 133. Valid options include utilizing a shadow of the
national/task force DIB maintained locally within the Border DSA, chaining the query
onward into the national/task force domain, or providing a referral to a specific internal
DSA that can be accessed by the user. A nation/task force may designate any number of
DSAs as Border DSAs.

DUAS

227. The directory access facilities required by the Allies dictate that DUA
functionality is provided in a number of forms. DUA functionality will be embedded into
commercial products which provide the user desktop services. It is no longer envisaged
that information retrieval for Message Transfer Agents (MTAs) and other messaging
processes is provided other than within the National Domain, and therefore is not
considered further.

228. DUAs make requests on behalf of the directory user and present results back to
the user. For example, a user can request the Originator/Recipient (O/R) address of a
messaging user in another country. DUAs are interconnected with DSAs (possibly
including Border DSAs within other Nations or Coalitions).

229. The degree to which a DUA is integrated with another application, e.g., a Military
Messaging User Agent (MMUA) or Mail List Agent (MLA), varies according to the
application, its implementation, and the degree of human involvement in directory
information access. A DUA may also be an entirely independent application, requiring
no user interfaces to operate.

230. ACP 133 defines three types of DUA functionality. DUAs with different
functionality than is defined here may be used as a national option 2 :

a. An “Interrogation” DUA uses the Read, Compare, List, Search and

Abandon services only. This type of DUA enables directory users to
request information from entries. These services may be constrained by
the limitations of the DUA, and they are limited by the DSA access
controls. A DUA of this type only requires read-only access to a DSA;

2 It should be noted that LDAP only provides a subset of the operations listed in the
following paragraphs, although the same effects can be achieved using a combination of
the available operations.

2-9 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

b. An “Interrogation/Modification” DUA uses all of the Directory services.

Such a DUA enables directory users to obtain information by directly
reading an entry or by locating interesting entries based on their content or
partial name as well as providing the ability for the user to modify entries.
These services may be constrained by the limitations of the DUA, and
they are limited by the DSA access controls; and

c. An “Administrative” DUA uses all of the Directory services. This type of

DUA enables a directory user to act as a Directory System Administrator,
creating, modifying, and deleting user entries and directory operational
information. Access controls may be used to limit what functions of an
Administrative DUA may be used by a specific user.

231. Authentication of DUAs is addressed in paragraph 405.

232. A DUA may receive a continuation reference when a DSA responds to an

operation by issuing a referral to another DSA. A DUA might also receive a continuation
reference as part of an incomplete List or Search result.

233. Some DUAs may be designed for use in environments where such references are
never used, or a DUA may be simplified such that it cannot pursue a reference.
Alternatively, a DUA may be designed to be capable of pursuing references. Another
possibility is that a DUA product is designed to be configurable such that the capability
to pursue references may be controlled (either by the user or by the system
administrator). In any case, when a DUA does not automatically pursue a continuation
reference, the reference shall be passed to the user so that a procedure can be used
instead.

234. Continuation references received in List or Search operations shall be handled by

the receiving DUA (by displaying them, etc.); however, their automatic continuance by
the DUA will be subject to national policy. In general, so that search or list loops are
deleted, it is preferable that continuation references be performed by DSAs rather than by
DUAs.

2-10 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

Section V - Protocols
GENERAL

235. To ensure interoperability among DUAs and DSAs from different nations, the
X.500 standard protocols are used for Allied Directory communications. These protocols
are:

a. DAP;

b. DSP;

c. DISP;

d. DOP; and

e. LDAP.

236. Use of these protocols may be a requirement within an Allied or CTF domain
dependent upon the architecture chosen. Otherwise, use of these protocols within a
national domain is outside the scope of this ACP.

DAP

237. DAP is used to convey requests for directory information to a DSA and to return
the results to the DUA. DAP is usually only used within a national or CTF domain
between a DUA and an internal DSA. If the architecture permits, DAP may also be used
between a DUA and a Border DSA in another domain and between a DUA and a DSA in
a CTF domain.

DSP

238. DSP is used to convey an information request to another DSA when the
requesting DSA does not have the complete information requested (i.e., to perform
chaining and to return the results to the requesting DSA). If allowed by the architecture,
DSP may be used between Border DSAs in different domains and between a DSA/Border
DSA and another DSA in a CTF domain.

239. When requested information is not present in the home DSA, chaining is
preferred over referral for access to the international information. To access information
that is specific to country B, a DUA within country A would access the directory through
its home DSA. The home DSA would chain the operation to the appropriate Border DSA
within country A. Depending on the specific information requested and on the
shadowing agreements that are in place, the country A Border DSA may either complete
the operation locally or further chain the operation to a country B Border DSA.
Similarly, the Border DSA in country B may contain a master or shadow copy of the
desired information, or it may chain the request onward within country B. Both chaining

2-11 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

and referrals may need to be supported in the Allied Directory dependent upon the
architecture chosen.

DISP

240. DISP is used to replicate information in the Allied Directory by conveying

shadow copies of directory information from one DSA to another. DISP may be used
between Border DSAs in different domains and between a DSA/Border DSA and another
DSA in a CTF domain, or between a Border DSA and a centralized Hub DSA, managed
within the Allied Domain. Prior to using DISP, an agreement to shadow is arranged and
activated. In the DSA sending the shadow, the information may be the master copy or a
shadow copy of the information. Both primary and secondary shadowing shall be
supported.

DOP

241. DOP is used to activate, deactivate, and modify shadowing agreements that have
been arranged between DSAs and to exchange knowledge and access control, collective
attributes, and other administrative information contained in subentries. DOP is used
between Border DSAs in different domains and between a DSA/Border DSA and another
DSA in a CTF domain.

UNDERLYING PROTOCOLS

242. All of the Directory protocols described above require use of the Association
Control Service Element (ACSE) and operate over the Presentation and Session Layer
protocols. These protocols are profiled in ISO/IEC ISP 15125-0, Common Upper Layer
Requirements (CULR) for the Directory. Below the Session Layer, the directory
applications require a connection-oriented transport service that may be provided in a
variety of ways, depending on the underlying networks and internetworking environment.

LDAP

243. LDAP was created for small, end-user clients, such as personal computers, to
provide lightweight access to an electronic directory. It simplifies the client
implementation by using text string variants of the most commonly required X.500 data
structures and cutting out some X.500 functionality that was considered unessential. The
protocol stack for LDAP avoids the overhead of session or presentation layer protocols,
but these savings may be offset by the additional size of data when encoded as a text
string.

244. The original LDAP (RFC 1487) specification was made obsolete by LDAP
version 2 (LDAP v2), covered by RFC 1777. In turn, LDAP v2 has been largely replaced
by LDAP v3 (RFC 2251). All protocol elements of LDAP v2 are supported by LDAP
v3. A large number of implementations of LDAP exist, including versions from all the
major systems providers, particularly the major Internet web browsers. Directory System
Agents (DSAs) implementing LDAP v3 should be able to support access from clients

2-12 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

using LDAP v2; similarly clients using LDAP v3 should be able to access servers using
LDAP v2 provided that the additional features of LDAP v3 are not used.

245. Part of the LDAP protocol is specifications for the X.500 directory data structures
in terms of text strings. These parallel structures significantly simplify the directory
client implementation by minimizing the amount of processing necessary for user input
before it is sent to the directory server. Recognizing these structures is an essential
component of any directory system implementation of this protocol. String
representations are defined in ACP 133 SUPP-1.

246. LDAP is designed to operate over the Internet communications protocols

Transmission Control Protocol (TCP)/Internet Protocol (IP) or User Datagram
Protocol (UDP). In addition, LDAP can be used with any underlying protocol that
provides an equivalent connection-oriented mode or connectionless mode service.

247. To be used to access the Allied Directory, LDAP clients must support the
ACP 133 schema for applications such as military messaging. The ACP 133 schema
includes definitions not included in LDAP Request For Comments (RFCs). LDAP
clients may be configurable to recognize new attributes. If the attributes have syntaxes
not defined for LDAP, such as OR-Address, implementations may be affected.

248. The limitations that affect interrogation operations are that LDAP:

a. Does not support the “dontUseCopy” service control;

b. Does not support the Read and List operations and uses Search as an
alternative, which may result in superfluous chaining; and

c. Does not support the Priority service control.

249. In addition to the limitations for interrogation operations, others that affect the
administration of the Directory are that LDAP:

a. Does not support some service controls and critical extensions;

b. Does not support signed operations; and

c. Does not support the selection of master or replicated directory entries.

250. Because of the limitations in LDAP, ACP 133 recommends that LDAP not be
used for directory modification, especially by Directory administrators, but be used
primarily for interrogation DUAs, where read-only directory access is required.

DIRECTORY DATA REPRESENTATIONS

251. As well as the use of existing protocols to access the directory and to share
information, other mechanisms exist which may be equally appropriate for directory data
exchange and access. Those specifically included in ACP 133 are:

2-13 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

a. LDIF; and

b. DSML.

LDIF

252. LDAP Data Interchange Format (LDIF) describes a file format suitable for
describing directory information or modifications made to directory information. The file
format is typically used to import and export directory information between LDAP-based
directory servers, or to describe a set of changes which are to be applied to a directory.
LDIF is specified in RFC 2849.

253. Certain Allied directory exchange mechanisms, including the Enhanced Griffin
Directory Service, as defined in ACP 137, use LDIF to exchange directory information
between nations, using informal or Military Messaging as the transport mechanism,
including the LDIF as an attachment to the message. This removes the need to hold
information in the central management domain, whilst making copies available in each
National domain.

DSML

254. The Directory Services Markup Language (DSML) provides a means for
representing directory structural information as an XML document. The intent of DSML
is to allow XML-based enterprise applications to obtain information from a directory in
their native environment. DSML allows XML and directories to work together and
provides a common ground for all XML-based applications to make better use of
directories.

255. DSML is intended to be a simple XML schema definition that will enable
directories to publish basic profile information in the form of an XML document so that it
can be easily shared via native Internet protocols (such as HTTP or SMTP), as well as
used by other applications. The principal goal is to ensure that directories are able to
make a growing breed of XML based applications directory aware.

256. It is not an initial goal of DSML to specify the attributes that all directories must
contain, or the method with which the directory information is accessed from the
directory. The expectation is that standard protocols (such as LDAP), proprietary access
protocols (such as Novell's NDAP) and proprietary APIs (such as Microsoft's ADSI)
could produce DSML documents as an optional output.

257. It is anticipated that DSML will become a key enabler for directory access in the
future. However, it is still a fairly immature technology and hence is not discussed
further at this time, but developments should be tracked to monitor progress and stability
in the area.

2-14 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

Section VI - Architectural Models

258. Recent work on the implementations of Allied Directory Systems has been
primarily oriented towards the replication model, whereby participating nations and
coalitions share directory information by copying it into and out of an Allied Domain via
Border DSAs, rather than the use of chaining or referrals to access DSAs within other
domains. This is primarily to circumvent problems of security as other mechanisms
would require external access within a national boundary. Many systems require the use
of gateways and firewalls at the boundary of the national system; these constrain the
protocols and services which are allowed through, DSP not normally being allowed.

259. Even within a replicated architecture, there are many different mechanisms which
may be employed to implement a solution. Questions which need to be resolved when
choosing an architecture, include:

a. Which protocols are allowed for replication? Whilst DISP is the obvious
choice, other solutions need to be considered either because DISP is not
supported through the gateway or for operational and management
reasons.

b. Does the architecture require a central “Hub” service, with each nation
representing a “Spoke”, all interconnecting with the centre, or does a
“Mesh” architecture represent a better solution?

c. How are Access Control, Data Separation and other data management
issues handled within the architecture?

260. This section considers various alternative Replication based solutions.

PROTOCOLS SUPPORTED

261. ACP 133 no longer constrains the protocols which may be employed to achieve
data replication within an Allied Directory System. Whilst DISP is the obvious choice,
since it is a well defined protocol which is available from many sources as a COTS
product, DISP does suffer from a number of problems which are listed below. Thus
whilst DISP may be the chosen solution, it is important that these potential issues are
understood:

a. Whilst DISP replication from a single vendor can work very well,
interoperability between vendors has been found to be difficult to achieve
in practice. In the event of failure to replicate between DISP systems from
different vendors, diagnosis is extremely complex since the data
transferred can be extremely large. Interoperability analysis is probably
an order of magnitude more complex than for messaging, where Protocol
Data Units (PDUs) are fairly easy to capture and analyze;

b. If schemas are not identical, replication is rarely successful;

2-15 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

c. The fallback mechanism employed by DISP in the event of a replication

failure is to replay ALL replicated data. During the replay process some
implementations make all data being replicated inaccessible, possibly for
an extended period. In addition, the effect of a complete replay of all data
on a bandwidth constrained network could have a catastrophic effect on
key military services;

d. Many DISP products have not given sufficient thought to the management
of DISP in a complex operational environment. For example, a managed
replay of data under user control when bandwidth is less constrained
should be allowed; and

e. Although DISP provides some limited capability for controlling the data to
be replicated (e.g., CHOP), these have been found in practice to be of
limited use in the military and more importantly deployed environment.
Whilst some products allow the list of attributes which are replicated to be
managed, there is no mechanism for controlling which entries should be
replicated or not.

262. Alternative replication mechanisms which may be chosen in preference to DISP

include use of a COTS or bespoke MetaDirectory product, usually supporting the LDAP
protocol for data access. In some situations, especially when a central Hub solution is
chosen, more than one protocol could be allowed, thus giving nations a choice as to
which solution to apply. In some highly constrained environments, where the protocols
supported between the national and shared network domains are extremely limited, the
use of a messaging service (which is often the only choice available) to transport
directory data to be replicated may be the only (or preferred solution). LDIF is ideal for
transporting directory information as an attachment to a message, although the time taken
for updates to be replicated may then not be deterministic.

263. One of the key characteristics of DISP is that replicated data may not be modified.
From a security perspective, this is often considered to be an advantage, by ensuring that
data cannot be modified other than within the local domain, possibly avoiding denial of
service issues. If other solutions than DISP are allowed, the need to secure the incoming
data from inadvertent or malicious changes may need to be considered within the
architectural design. Conversely, the development of international Military Messaging
solutions has indicated that the ability to modify received information (such as addresses
to make them valid locally) may be necessary.

SERVER ARCHITECTURES

264. Two architectures have been identified within the Replicated data model, either
Hub and Spoke, as depicted in figure 2.3 and a Mesh as depicted in figure 2.4. In both
cases, each participating Nation, Organization or CTF interfaces through a Border DSA,
which contains only that information which may be shared, thus ensuring that nationally
private data, which may not be shared, is not accessible. Note that in both figures, other

2-16 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

Security Enforcing components, such as Gateways and Firewalls are not shown. In most
systems, these would be necessary to ensure national data security.

Figure 2-3 – Example Hub and Spoke Architecture

265. The Hub and Spoke architecture is most suitable for a large number of
participating Nations or CTFs, since each Border DSA only needs to connect to a single
Hub server. Only one outgoing replication agreement (to the Hub) is required, plus one
agreement for each other participating Nation/CTF from which it requires data. The Hub
is responsible for replicating each nation’s data to all others. The Hub and Spoke
architecture insulates each nation from the need to test with all other nations; only the
connection to the Hub need be proved before connection.

266. One of the key issues with Hub and Spoke is provision of the Hub service within
the network (although in practice this could be held within one participant’s domain). In
addition, data separation is not possible in the case where different data may be shared
with different nations. Unless the Hub management is cleared to see the superset of all
data, security issues will ensue.

267. The Mesh architecture is preferred only where the number of participants is
limited; otherwise the number of replication agreements can become unmanageable. In
addition, since each nation has to connect to all other nations, the solution is only

2-17 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

recommended where well trusted and proven protocols are employed for data replication.
This architecture is also recommended when nations must send different directory data to
each other nation (such as when different subsets of entries or attributes may be allowed),
since there is no need for all data to be held within a central hub.

Figure 2-4 – Example Mesh Replicated Architecture

DATA SUBSETTING, SEPARATION AND CHANGE MANAGEMENT

268. As has been mentioned earlier, DISP does not provide usable capabilities for the
subsetting of a national DIT and replicating certain entries but not others. Various
solutions have been suggested for this, possibly the most appropriate being to define a
multi-valued attribute within each entry, thus allowing entries to be tagged from which
replication decisions can be made (e.g., “Griffin” Tag for indicating entries which can be
shared over the Griffin network). Some vendors are investigating whether they could
enhance their DISP implementation locally to replicate based on a defined rule set, but
these products are currently immature and use proprietary mechanisms.

269. DISP provides the ability to replicate data incrementally on change, thus
providing a very efficient way of replicating both from a nation to a Hub and from the
Hub into other nations which have copies of the information. It achieves this using
administrative attributes which would be inaccessible to an LDAP application. There is

2-18 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

therefore no standard way of easily identifying changes which have occurred, making
incremental updating more difficult and “On Change” replication impossible, unless
proprietary mechanisms have been defined by the Hub provider. A number of attributes
have been added to ACP 133 to facilitate this process; these include entry creation time
and date, entry last modified time and date.

270. Subsetting the DIT would normally only be performed locally to a nation, before
the Border DSA. Thus either a proprietary extension to DISP is supported to subset the
nation’s Enterprise Directory into the Border DSA, or a Meta-Directory tool is needed to
perform a similar function between to the two. It is highly likely that nations will need to
employ some form of COTS or bespoke Meta-Directory tool, either between the national
DSA and their Border DSA or between their Border DSA and a central Hub. This can
take care both of subsetting of data and where necessary, modifying received data to
convert from external to national-specific format.

USER ACCESS TO DATA

271. In the replicated model, user access is normally only allowed within the national
domain, thus all incoming data from other participants is replicated to the national Border
DSA, from where it will be copied to a user accessible DSA. Users would not normally
be allowed to access data beyond the national Border DSA.

2-19 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

Section VII - Security of The Directory

SECURITY MECHANISMS

272. The Directory protocols include security mechanisms that meet the security
requirements for the Allied Directory System. Therefore, no additional protocols are
employed to protect the Allied Directory System and Services.

2-20 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

Section VIII - Management Of the Directory

MANAGEMENT ARCHITECTURE

273. Figure 2-5 illustrates a model for systems management interfaces for the
Directory. The interfaces that do not indicate a protocol, such as, between a DSA and a
management agent, are not standardized.

Figure 2-5 – Model for Management of the Directory

274. All aspects of management leading to processing, recording, communication and
logging of information shall be configurable.

275. Those protocols and components outside of the core Allied Directory are privately
managed and beyond the scope of this ACP.

MANAGEMENT PROTOCOLS

276. Management protocols, such as Common Management Information

Protocol (CMIP) or Simple Network Management Protocol (SNMP), are outside the
scope of this ACP.

TIME AND DATE STORAGE

277. GeneralizedTime. GeneralizedTime shall be used for all directory related date
and time exchanges between nations. GeneralizedTime values shall be expressed as
Greenwich Mean Time (Zulu) and shall include seconds (i.e., times are
YYYYMMDDHHMMSSZ), even where the number of seconds is zero.
GeneralizedTime values shall not include fractional seconds.

2-21 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

278. Certificate Validity. The certificate validity period is the time interval during
which the CA warrants that it will maintain information about the status of the certificate.
The field is represented as a sequence of two dates as defined above: the date on which
the certificate validity period begins (notBefore) and the date on which the certificate
validity period ends (notAfter). Both notBefore and notAfter may be encoded as
GeneralizedTime.

279. Audit Trails and Engineering Logs. Although it is unlikely that audit trail
information and engineering log information from ACP 133 (interworking) systems will
be exchanged between allies, it is requested that all the support and management facilities
of ACP 133 compliant systems use GeneralizedTime. Each nation should request such
compliance for these management areas when selecting their products/vendors.

2-22 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

CHAPTER 3

DIRECTORY INFORMATION POLICIES AND PROCEDURES

Section I - Schema Definition

SCHEMA OVERVIEW

301. The schema policy for ACP 133 is to support the Allied Directory schema using
the schema specifications given in ACP 133 SUPP-1. The Allied Directory schema,
which is called the Common Content, includes the specification of user information
stored in the Directory. An additional Allied Directory system schema, which may be
required by X.500 implementations, includes the specification of information that is
required to control and manage the DSAs themselves is beyond the scope of this ACP.
Support for a schema means that a DUA or DSA shall be able to handle the information
types (e.g., entries, object classes, attribute types etc. defined in ACP 133 SUPP-1). This
is a key requirement for successful interoperability between Allied nation’s directory
services.

COMMON CONTENT

302. The Common Content includes object classes, name forms, structure rules,
matching rules and attributes from the X.500 and X.400 standards, from Request for
Comments (RFC) 1274 and 2798, and those defined in this ACP. The types of attributes
that are present in a directory entry are dependent on the object class or classes to which
the entry belongs. ACP 133 specifies the attributes and object classes in the Common
Content that must be supported for military applications.

303. Requirements and guidelines for population of the Common Content for specific
applications are described in this ACP. Nations may need to define additional objects
and attributes for local use. The schema for the Allied Directory does not preclude such
extensions. However, the additional information stored in national extensions may not be
replicated between nations unless specific bi-lateral arrangements are made for their
support on both the supplier and consumer systems.

304. For the interoperation of ACP 127/JANAP 128 systems and ACP 123 systems,
provision is made in the Common Content for including information about PLAs.

305. The Allied Directory System shall enforce the Common Content to ensure that
replication between nations is possible and the structure and contents of the DIB remain
well-formed over time as modifications are made. Action must be taken by nations to
prevent the wrong attributes being added for an object, to ensure that the values are in the
correct form for the attribute type and to ensure that entries are correctly placed in the
DIT.

3-1 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

DIRECTORY ENTRIES

306. Each entry within the Allied Directory DIT is made of an entry type as defined in
Section 6. Each entry is made up of a Structural Object Class (SOC), plus a number of
Auxiliary Object Classes (AOC), which are allowed for that SOC. These Object Classes
define the mandatory and optional attributes which may be contained within them.
Object and Attributes are fully defined in ACP 133 SUPP-1, including their syntax,
matching rules etc. Directory entry type definitions are not shared using DISP or other
replication mechanisms, rather they are “virtual” definitions used to group allowable
Object Classes together.

307. In addition to the SOCs, and the AOCs which may be contained within them,
directory entries also require the structure rules which define which entries may be
present above and below them in the DIT. These rules are listed in Chapter 6.

DIRECTORY NAMES

308. Each nation or international organization is responsible for assuring the

uniqueness of names in its subtree.

309. The DIT should be organized to keep the number of levels as few as possible
since fewer levels are preferable for ease of directory browsing.

310. An entity must have a single unique identity. An entity may also be associated
with multiple other entries; for example, one person may have one entry as an individual
and may be associated with one or more roles such as a security officer etc. The person's
distinguishedName would be included in the entry for the role as role occupant.
Alternatively, many individuals may support a single role function. The commonName
would reflect the role name. The seeAlso attribute may be used to cross-reference the
entries holding the other identities.

311. Additional values besides the distinguished value may be included in naming
attributes, although this practice is not advised since some implementations may not
correctly return matching values. An additional name allows for different values to
produce a successful result when searching for an item in the Directory. For example, the
commonName attribute could include the Relative Distinguished Name (RDN) value e.g.:

Smith, Robert K plus an additional name Bob Smith.

312. Note that an additional attribute, displayName, has been included in the schema to
allow a different, preferred way of representing the entry in a flat list such as the MS
Exchange Global Address List (GAL).

3-2 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

313. Each entry in the Allied Directory has a unique and globally unambiguous name,
the Distinguished Name (DN), which is composed of the values of the attributes,
indicated for naming in the DIT. For example, a person’s name could be:

c=US, o=U.S. Government, ou=DoD, ou=Navy, ou=locations,

l=Washington DC, cn=Jackson, Robert

314. The values of attributes composing directory names (i.e., DNs) should be kept as
short as possible while remaining meaningful and unique.

315. In order to avoid reassigning users’ directory names each time they are promoted,
a rank indication shall not be included in the commonName distinguished value of the
relative RDN attributes of persons. The rank attribute should be used for this purpose.

316. When creating a directory name, any appropriate combination of upper and lower
case characters may be used in character string values, as directory operations are case
insensitive in matching character strings for selecting an entry.

317. Use of characters from other national language sets than A-Z are for further study,
primarily within NATO, in which there is a more compelling need to handle additional
characters. In the meantime, ACP 133 mandates that naming attributes may ONLY
contain characters from the ASCII range 32 to 127 for international interoperability, to
ensure that they can be rendered and handled correctly in search and browse operations
regardless of character sets actually supported in the receiving nation.

318. Using a DN qualifier as a second component of an RDN to identify an entity in

the directory uniquely is permitted for some types of directory entries, although it is
unlikely other nations would understand the subtleties of its use within the nation. Its use
is therefore not recommended. For example, the RDN of an ACPOrganization entry
could be a distinguished value of organizationName plus a distinguished value of
dnQualifier:

a. In order to ensure that these qualifiers are used in an optimal way, the
following naming policy is recommended:

(1) Where possible, the RDN should consist of a single component,

(2) Since conflict may arise with some object names, provision is
made for the DN Qualifier to be used in addition to the mandatory
naming attributes for ACPOrganization,
ACPOrganizationalPerson, ACPOrganizationalRole and
ACPOrganizationalUnit entry types. This DN Qualifier must be
locally administered, and

(3) In the directory systems that support Certificate Management

Infrastructure (CMI) applications, it may be desirable to organize

3-3 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

the CA’s certificate and user’s certificate release information that

have common properties into “domains”;

b. This directory organization optimizes the certificate path processing and

CA operational management. When organized in such a fashion, CA
directory entries require a multi-component RDN. ACP 133 satisfies this
requirement by permitting DN Qualifiers for ACPOrganization,
ACPOrganizationalUnit, ACPOrganizationalPerson and
ACPOrganizationalRole entries; and

c. The use of DN Qualifier in ACP 133 has the semantics of a unique

identifier and not the precise meaning as defined in X.520.

319. Although the localityName and stateOrProvinceName attributes are optional in

the locality object class in X.521, one or the other of them shall be present in Locality
entries in the Allied Directory because they are the naming attributes for localities.

320. The RDN shall not include the full stop character (period), even when an
abbreviation is included in the value. Likewise use of comma is allowed but its use
should be minimized since it can cause difficulties for some applications which treat
comma as a delimiter character (c.f. MS CSV files).

321. The distinguished value of commonName of an ACPOrganizationalPerson entry

shall be nationally defined. However, the order last name, first name, middle initial(s),
generation qualifier is recommended. Other values of commonName may be ordered
differently.

322. A directory entry may have one or more alias entries that point to it. For
example, an Electronic Data Interchange (EDI) party name may be an alias that maps to
the Directory name of an organization. Another example is the temporary maintenance
of an alias for an individual at one location when he has been transferred to another
location.

323. When aliases are used, there is a need to keep them synchronized with the DNs
they point to. Standardized management tools will be needed to perform this
alias/distinguished name synchronization.

ORGANIZATIONAL ROLES

324. Provision is made in Common Content for nations to establish directory entries
for functional roles in addition to entries for individuals and organizations. These entries
will tend to be more stable than those for individuals and may be especially useful for
tactical organizations.

3-4 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

CERTIFICATION AUTHORITY FUNCTION

325. In the Allied Directory, a CA can be represented in the Allied Directory by use of
the pkiCA Auxiliary Object Class, which can be included in any of the following entry
types: ACPOrganization, ACPOrganizationalPerson, ACPOrganizationalRole and
ACPOrganizationalUnit. The naming conventions associated with each nation’s CA will
be in accordance with each nation’s Certificate Policy and Certification Practice
Statement (CPS).

ACP 127 USERS

326. In support of the ACP 127 Interworking application, two different approaches,
illustrated in Figure 3.1, are suggested for representing ACP 127 users (i.e., Plain
Language Addresses (PLAs)) in the Allied Directory System, depending on the national
view concerning integration of ACP 127 information with other information in the DIT.
A nation may choose which method it uses in its own DIT subtree to capture PLA
information. However, a national schema should support the elements of both methods
in order to be able to handle PLA information that may be represented differently in other
nations’ DIT subtrees.

327. One method is to place PLA-related information in ACPOrganizationalUnit

directory entries in the same subtrees as the information for the other applications
(i.e., “share” the entries). In this case, the aCPPlaUser auxiliary object class shall be
used to store the PLA and Routing Indicator (RI) in the organization's entries in the
Allied Directory System. This allows the organization's subtree to be searched to find the
PLA and RI information.

328. The other approach is to have separate subtrees in the DIT for PLA-related
directory entries (e.g., aCPOrgACP127 entries) and for directory entries supporting the
other applications. Using this approach, from the ACP 127 domain, the gateway will
search a PLA subtree for an associated aCPOrganizationalUnit entry where an O/R
address is found. This entry shall have an associatedPLA attribute which points to the
associated aCPOrgACP127 entry. RI information will be contained in a directory in the
ACP 127 domain

329. Note that PLA is called Signal Address (SA) or Signal Message Address (SMA)
by some nations and international or multinational organizations. A registered PLA is
equivalent to SA or SMA. In this ACP, the attribute longTitle is defined for storing the
spelled out (long form) of a PLA, SA, or SMA.

3-5 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

Figure 3-1 – Methods of ACP 127 Interworking

USE OF THE SEEALSO ATTRIBUTE

330. The correct use of the seeAlso attribute can benefit Allied Directory System users.
Conversely, poor use of the attribute can have an adverse effect on performance of the
Allied Directory System and create frustration for users and impose an additional burden
for directory administrators. It is the responsibility of the directory administrator to
ensure that the seeAlso attribute values are valid and do not point to non-existent
directory entries.

3-6 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

Section II - Entry Population and Usage

331. This section is intended for administrators who are planning for or are populating
the directory entries in the Allied Directory System. Population refers to the directory
entries and attributes for which values should be made available in the Allied Directory to
support given user applications. There are many different uses to which the Allied
Directory Service can be made, including:

a. E-mail communication (non-X.400);

b. Secure Multi-purpose Internet Mail Extension (S/MIME);

c. Commercial MHS communication;

d. MMHS communication;

e. Communication between MMHS users and ACP 127 users; and

f. Contact Information (e.g., telephone, facsimile and postal mail).

332. Table 3-1 indicates typical directory entries which may be required for each type
of directory usage. This list is not intended to be exhaustive, but to give an indication of
the likely entries required.

333. For e-mail communication (non-X.400), the directory entries and attributes shall
normally contain the common name and mail (RFC 2822) address.

334. For S/MIME communication, the directory entries and attributes shall contain the
common name, mail (RFC 2822) address and user certificate.

335. For commercial Message Handling System (i.e., civilian X.400) communication,
the directory entries and attributes shall contain the information necessary for performing
the core functions of a messaging system. These functions include, but are not restricted
to addressing, routing, expanding address lists and directory access.

336. For MMHS and e-mail services with confidentiality and digital signature features,
the directory entries and attributes shall contain the information necessary for performing
the core functions of a secure messaging system. These functions include addressing,
routing, securing a message, translating from one type of messaging protocol into
another, expanding address lists, and directory access.

337. For interworking between the ACP 127 and MMHS systems, the directory entries
and attributes shall contain the information necessary to identify and characterize
ACP 127 users and to utilize the gateway(s) between the two systems.

3-7 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

338. In order to support traditional contact information, such as telephone, facsimile

and postal mail, the directory entries and their associated attributes shall contain the
information necessary for human users to look up someone else’s information by
providing a common name of an organizational person, or organizational role, or the
organizational unit name of an organization. The directory serves as a repository of this
information, and after the user gets the information from the directory, the rest of the
communication takes place using the traditional communications network.

339. Table 3-1 indicates, for each application, the directory entries that would normally
be required for Allied communication whether specified by the standards or in the
Abstract Syntax Notation One (ASN.1) definitions in this ACP. If the directory entry is
required, then it is indicated by a “•” to highlight that the Allied Directory shall contain
directory entries of that type.

Entry Type E-MAIL S/MIME Com- MMHS ACP Contact

mercial 127 Inform-
MHS Inter- ation
working
1. ACPAddressList • •
2. ACPCRLDistributionPoint • •
3. ACPGroupOfNames • • •
4. ACPOrganizationalPerson • • • • •
5. ACPOrgACP127 •1
6. ACPOrganizationalRole • • • • •
7. ACPOrganizationalUnit • • • • •
8. ACPPLACollectiveACP127 •
9. ACPTaskForceACP127 •
10. ACPTenantACP127 •

Table 3-1 – Population of Directory Entries for Applications

1
The requirement shown applies only when the “separate subtree” method is employed, as
described in paragraph 328.

340. In addition, entries for Country, Organization, Organizational Unit, and Locality
may need to be populated in order to provide structure for a nation’s DIT.

3-8 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

Section III - Registration

REGISTRATION REQUIREMENTS

341. The following objects need to be registered to ensure that they are globally unique
within the Allied Directory System:

a. Technical Object Identifiers;

b. Directory DNs; and

c. Other information stored in the directory, e.g., addresses.

TECHNICAL OBJECT IDENTIFIER

342. Object Identifiers (OIDs) provide a unique reference to the definition of technical
objects. This includes technical objects which are specific to the directory such as object
class and attribute definitions, as well as technical objects which have wider relevance
such as certificate policy identifiers. Other applications such as Open Systems
Interconnection (OSI) management and messaging also make use of Object Identifiers to
reference technical definitions.

343. Object Identifiers for standard technical definitions are allocated in the standard
where they are defined (e.g., X.500 allocates Object Identifiers for directory object
classes and attributes defined in that standard).

344. Object Identifiers for new schema definitions for object classes, attributes, name
forms, etc., for the Allied Directory are defined in this ACP (see ACP 133 SUPP-1) under
the parent Object Identifier.

345. joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101) dod(2) ds(2).

346. National or other new schema definitions outside the scope of this ACP are
allocated Object Identifiers under the appropriate national or international Object
Identifier registration scheme.

DIRECTORY DISTINGUISHED NAMES

347. A DN is a sequence of naming attributes which uniquely identify an object which

may be represented by an entry in the directory. Objects that may be identified using a
distinguished name include organizational units, people, roles, address lists and devices.
A Distinguished Name is used as the primary "key" to locate an entry in the Allied
Directory. In addition, Distinguished Names are used to identify the “subject” of an
X.509 public key certificate.

348. The naming attributes which form a DN, are organized in a hierarchy reflecting
the DIT with a name lower in the tree identified relative to its parent entry by adding
RDN attributes to the parent's DN.

3-9 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

349. Before an entry is created for an object in the directory (or a certificate created for
that object) it must be allocated a unique DN. The allocation of a distinguished name in
the Allied Directory is the responsibility of the Registration Authority for the Service,
agency, or command to which the named object belongs. A registration authority may
delegate responsibility of directory distinguished name registration for subtrees within its
domain to Sub-Registration Authorities. A registration authority (or sub-registration
authority) may also take on responsibility for registration of other identifiers including
technical object identifiers and addresses (see below).

350. The registered DNs relevant to the Allied Directory may be disseminated through
the directory.

GENERAL REGISTRATION REQUIREMENTS

351. The directory can be used to store addressing and other related information. As
with DNs, these addresses need to be unique within the global context and hence must be
allocated under a registration scheme. Examples of information requiring registration are
X.400 MHS Addresses (including Private Management Domain (PRMD) identifiers),
OSI network addresses and Internet Protocol addresses.

352. The specific registration requirements for the registration of information, such as
addresses, is dependent on the type of communication or application service to which the
information applies, and is hence outside the scope of this ACP. However, objects which
are allocated DNs commonly also require addresses (e.g., X.400 addresses) and hence the
various registration functions should be coordinated using coherent registration
procedures.

3-10 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

Section IV - Shadowing Policies

353. A Shadowing Agreement Checklist is initiated by the administrator of the supplier
DSA, who administers the information requiring shadowing. The Shadowing Agreement
Checklist is filled out and provided to the consumer DSA administrator for completion
and agreement. The Shadowing Agreement is reviewed and approved by the Directory
Services Manager. The agreement shall state the protection provided to shadowed
information. Also, when agreement involves secondary shadowing, the Shadowing
Agreement Checklist is reviewed and approved by the DSA Administrator of the Master
DSA.

354. Directory information that is provided to the Allied Directory System from
national directories may be shadowed and individual entries within this information may
be incomplete. Thus, users may not find what they are looking for and require access to
the master or a complete replicated entry. In a directory system unconstrained by access
controls, users would be able to satisfy the request by chaining from the Border DSA into
the national directory. However, this situation may not be permitted. In order to satisfy
one nation’s directory queries of another nation’s Border DSA, consideration should be
given to the way in which replicated data is marked. The options are that the data may be
marked as a master or copy. If it is a copy, it may be marked as incomplete. If it is
marked as incomplete, it implies that chaining is permitted into the directory that contains
the complete entry. This may be a national DSA or another Border DSA. How data is
marked should be specified within the allied Service Level Agreements (SLAs).

3-11 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

Section V - Chaining Policies

355. All Border DSAs and DSAs in combined task forces shall be capable of
supporting both chaining and referrals if the Allied Directory architecture is based on
chaining and referrals.

356. Either chaining or referral may be used as long as performance and security
requirements are met.

357. In the service controls, Prefer Chaining shall be the favored option. However, use
of Chaining Prohibited is permitted.

3-12 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

Section VI - Directory System Performance

GENERAL

358. The Allied and the supporting national directories, which combine to form an
overall directory service capability for the allied forces, must have realistic performance
characteristics. Performance can be seen in a number of ways namely: ease of use,
robustness, timeliness of service restoration, and speed of access response.

EASE OF USE

359. Ease of use is a factor of the system design and the tools presented to the directory
user such as click and point, icons, windows, scripts, status messages, etc. This aspect of
the system is beyond the scope of this document but will be subject to national system
Concepts of Operations (CONOPS), policies, and procurement procedures.

ROBUSTNESS

360. Robustness deals with product and system reliability and integrity. Again, these
will have to be specified in terms of Integrated Logistics Support (ILS) and Life-Cycle
Costing (LCC) needs and Mean Time Between Failure (MTBF)/Mean Time To
Repair (MTTR) type specifications. This is also beyond the scope of this document.

AVAILABILITY

361. The goal is to provide 24 by 7 availability of the Allied Directory Service.

SERVICE RESTORATION

362. Service Restoration deals with the recovery time for a single DSA to attain an
operational state after switch on or switching the DUAs (and other attached DSAs) to an
alternate DSA. This should not exceed five minutes if the DSA is in a strategic
environment. In a tactical environment, it should be less than one minute.

SPEED OF RESPONSE

363. For defining the speed of response requirements, the directory system can be seen
to provide two types of access characteristics. These are:

a. The human access requirements, which deal with organizational

information retrieval (such as postal and telecommunications information)
via a man-machine interface; and

b. Specific system functions (such as MTAs and UAs), which need to resolve
for example, names to addresses for message routing. This interface is
considered to be a machine-to-machine interface.

3-13 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

364. Both of the above have performance requirements. However, how these are
characterized and presented can be quite different. Underlying the performance of such a
large scale system is naturally the individual DSA performance and the links used
between them to other DSAs and the accessing DUAs. It is outside the scope of this
document to provide specifics of these, except that some general guidelines are provided
to assess the capability of a DSA platform and determine its accessibility and
performance in a distributed environment.

HUMAN INTERFACES

365. In terms of specifics, the human interface and its response requirements set the
directory performance requirements and thus impose the directory system design.

366. The directory user interface performance requirement is as follows:

a. All interrogation accesses satisfied in the home DSA shall be performed

within three seconds for a ten-kilobyte retrieval;

b. 95 percent of the intra-domain interrogation accesses shall be satisfied

within five seconds for a ten-kilobyte retrieval. Worst case shall not
exceed ten seconds;

c. 90 percent of the inter-domain interrogation accesses shall be satisfied

within 15 seconds for a ten-kilobyte retrieval. Worst case shall not exceed
20 seconds; and

d. An update operation to a single entry shall be performed within five

seconds.

OTHER APPLICATIONS

367. The Allied Directory System will be accessed for other purposes than supporting
the messaging function. Examples of functions for which the performance criteria for
directory access may be different from the messaging support criteria are:

a. Authenticating management entities; and

b. Distributing certificate revocation lists (CRLs).

PERFORMANCE CHARACTERISTICS

368. The following text provides some generalized notes that should be applied in the
procurement, design, and operation of the directory systems for both the national systems
and the shared/combined systems:

a. DUA Selection of Priority: In the human interface, there may be an

option for selecting directory access priority. Such a feature must be used
responsibly, considering DSA capacity and the relative urgency of the

3-14 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

request. The default for priority should be set to normal. It is

recommended that Urgent Priority directory accesses be reserved for
tactical operations;

b. DSA Priority Processing: DSAs should be capable of servicing the

priority field. However, this will depend on the queuing, processing
architecture, and DIT storage mechanisms that a DSA uses. Suffice it to
say that the operations in the input queues of a DSA must be serviced
according to priority;

c. DAP Service Parameters: The Size Limit and Time Limit Service
Control parameters should be defaulted to catch/inhibit any unexpectedly
large (gigabyte) responses or dead DSAs in the chain. For example, Size
Limit is defaulted to the number of objects that can be contained in
250 kilobytes;

d. DSA Performance Reporting: The DSAs shall provide performance

reports which demonstrate characteristics of population, speed of access,
speed of basic and filtered searches, and DIT modification/replication
actions;

e. DSA Association Limits: All DSAs shall support at least 100

simultaneous associations;

f. DSA Bind Time Limits: It shall take less than ten seconds for a DSA to
perform a Bind or Unbind with strong authentication with a DUA or other
DSA;

g. Bogus Searches: When a search for a bogus entry is instigated (e.g., find
bogus entry), the response shall be returned in less than 30 seconds,
preferably ten;

h. Access Control Processing: When access controls are applied to Reads,

Lists, and Searches, etc., to restrict access to identified users, they shall
not increase access time by more than ten percent of the time for
unrestricted access;

i. Chained Operations: When a Search is chained by a DSA (using DSP),

it is a DSA performance requirement that Search requests to the other
DSAs shall be initiated within ten seconds of the initial DSA access;

j. Performance Optimization Tools: It is possible that, as the allied system

evolves, utilities will be developed that do scripted actions on the directory
system. To assist in performance optimization of the Allied Directory
System, some form of service logging and tuning tools must be used;

3-15 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

k. Alias/List Utilities for DIT Integrity: To assist in DIT management,

alias integrity checking and clean-up facilities should be sought;

l. Replication Triggers and Consistency: When replication is used (via

DISP, etc.), mechanisms must be sought that control when an update takes
effect in the target DSA. This is necessary to prevent loss of data integrity
in a multi-processing environment caused by the data being “overwritten”
while a Search operation is also in progress; and

m. Performance Logs and Reports: DUAs and DSAs shall keep transaction
logs that support performance management and system planning.

DUA CACHING GUIDELINES

369. Employing DUA caching is a matter of national policy. When it is done, the
guidelines in this paragraph may be followed. Store cached information in nonvolatile
memory:

a. Treat cached entries and cached certificates separately for the purpose of
determining the useful life of the cached information. Extend the useful
cache period for the certificate, since it is a relatively static entity with its
own expiration time and revocation procedures;

b. Set the time-to-live for cached information according to the type of

information stored in the cache (individual or organizational), the function
of the command or persons operating the system, the maximum authorized
message precedence, the security classification of the information and the
DUA user, and the nature of the DUA;

c. Set the time-to-live for cached entries of individual users to expire within
a 15 day time period. Set the time-to-live for cached entries of
organizational users to have a maximum expiration period of four days;

d. Where an organizational user and individual user share the same DUA, the
expiration for the limit on the time-to-live conforms to that for the
organizational user. The local management center approves time-to-live
values in excess of these recommendations;

e. Capture and record, with the cached entry, the date and time that the entry
was last obtained in order to determine the expiration time of the entry;

f. Upon receipt of a CRL, all components containing cached certificates

compare the cached certificates against the list of revoked certificates and
purge those cached certificates matching the certificates listed in the CRL;

3-16 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

g. Cache expiration intervals are approved in advance by the local

management center. This is to avoid saturation of the directory for
inappropriate short intervals. The Local Center also requests that the
cache maximum time limits be raised for conditions where the directory
service is unable to provide adequate service; and

h. Purge a cached certificate upon the expiration date contained within the
certificate; and

i. Cache knowledge information of DIB distribution in DSAs, unless it

violates local security guidelines. This information may be used by DUAs
to gain direct access to desired information.

3-17 Original
UNCLASSIFIED (Reverse Blank)
 UNCLASSIFIED
ACP 133(D)

CHAPTER 4

DIRECTORY SECURITY POLICIES AND PROCEDURES

Section I - Security
SECURITY SERVICES

401. The security services defined within this section have been developed as
countermeasures against the perceived vulnerabilities of the X.500 model. This analysis
was based on X.509, Annex A. The security services defined below are considered
against the three general threats of unauthorized disclosure, modification, or
unavailability of information contained in the directory. The information is vulnerable
when held within a DSA or when transiting elements of the directory. The aggregation of
the total information shared within the allied directory may raise the level of security risk,
so although individual elements of information may be of low classification, the total
system may have to be considered at higher classification.

402. Not all security services will be applied to the information within the directory.
For example, confidentiality of information within the directory is only considered viable
when a small amount of information is at a higher classification level than the rest of the
directory and the information is to be shared amongst a small number of users.

403. Many applications and services will have requirements for security. Such
requirements are derived from the need to protect the information from a range of
potential threats. In order to protect against threats, security services shall be provided.
These services are:

a. Authentication;

b. Access Control;

c. Key Management;

d. Confidentiality;

e. Labeling;

f. Availability; and

g. Integrity.

404. These security requirements are only mandated within the international domain
and where X.500 services are being fully used. Within a national domain, they are to be
considered informational and advisory, since security within the national domain is a
national matter. Likewise, if non-X.500 methods (such as use of MetaDirectories or
LDIF) are used for sharing directory information from a national Border DSA to a central

4-1 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

service, they may also not be applicable. It is the responsibility of the organization
operating the central, shared service, or in a peer-to-peer topology, the partner nations to
ensure adequate security is provided.

AUTHENTICATION

405. Peer entity authentication is performed between DUAs and DSAs and between
DSAs to provide corroboration that a user or entity in a certain instance of
communication is the one claimed. ACP 133 shall support mutual authentication through
the use of strong authentication. Strong authentication relies on the use of asymmetric
encryption. Asymmetric encryption uses the combination of a public component and a
private component to sign digitally the credentials of the user or entity authenticating
itself to the system. A digital signature guarantees both the origin and the integrity of the
information that is digitally signed. This binding of the public key and its holder’s
identification information is conveyed through an X.509 certificate that is generated by a
CA. Each individual nation shall implement its own Certificate Management
Infrastructure (CMI) to include CAs in such a manner as to ensure the trusted path for
certificate management. In the case of a CTF, authentication policies and procedures are
under the control of the CTF commander.

406. The CMI is an integrated relationship of CAs and all the components necessary
that operate under the authority of either a superior CA or, in conjunction with bilateral
agreements, with other CAs.

407. The CMI includes the process for developing Certificate Policies. A Certificate
Policy is a named set of rules that indicates the applicability of a certificate to a particular
community and/or class of application with common security requirements. For
example, a particular Certificate Policy might indicate applicability of a type of
certificate to the authentication of electronic data interchange transactions for the trading
of goods within a given price range.

408. Each CA shall have a statement of the practices, the CPS, which it employs in
managing certificates.

409. Each nation’s CPS shall identify the procedure used to create, maintain, and
revoke credentials.

410. Two-way mutual peer-to-peer strong authentication shall be supported. Strong

authentication shall be used in the Allied Directory System where warranted. ACP 133
shall support attributes for Version 3 X.509 certificates and Version 2 CRLs.

411. Assurance is incumbent on the availability of public keys in a way that guarantees
that the public key really belongs to a particular identity. Validation of signatures is
based on the assumption that the authenticating entity has the correct public key. The
link between an identity and its public key shall be guaranteed. False identities and
substituted keys are serious threats to these mechanisms. Each CMI’s CPS shall ensure
that actions are taken to mitigate these threats.

4-2 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

412. Within the ACP 133 Directory system, all DSAs shall be able to process bind
requests that are simply authenticated and those that are strongly authenticated, utilizing
an agreed upon digital signature algorithm. DSAs shall support access control policy that
prevents unauthorized disclosure or modification of information based on the level of
authentication used. The DSA shall strongly authenticate itself to its communication peer
(i.e., DSAs, DUAs, and management entities) as required. The success or failure of the
steps in the authentication process shall be audited and stored in the DSA audit database
to facilitate compromise recovery and to enhance security of the Directory.

413. In the Allied Directory, the following additional security constraints shall be met:

a. Prior to exchanging any information, any pair of DSAs shall strongly

authenticate themselves to each other if required by security policy
between the two DSAs. Additionally, the DSAs shall not permit access to
any information until all access control checks have been performed and
granted;

b. Only approved cryptographic mechanisms for the DSA application and the
associated processes shall be used;

c. The DSA shall support a CMI-defined signature validation process. This

process shall include validating the CA which produced the certificate
used to sign the identification and authentication information (i.e., validate
the certification path);

d. If the claimed identity is not validated, the request shall be rejected and the
failure audited. Additional security actions may also be initiated; for
example, the DSA may lock out the user;

e. In those environments where Rule-based Access Control (RBAC) is

imposed, each entity shall exchange privilege/authorization information
required for the access control decision function, when performing the
strong authentication Bind operation;

f. Once the communications partners have successfully authenticated

themselves to each other, the DSA shall limit access to information stored
within its DSA according to the parent (host) system security policy; and

g. The DSA shall allow access and privileges to be set only by an authorized
management entity.

ACCESS CONTROL - GENERAL

414. The X.500 Directory standard defines three access control schemes: Simplified
Access Control (SAC), Basic Access Control (BAC), and RBAC. However, how that
information is stored within a country's directory is a national issue. The ACP 133 shall

4-3 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

mandate that directory systems ensure that the agreed-upon access controls are
maintained.

415. The access control mechanisms shall include both RBAC as well as BAC. RBAC
restricts access to objects within the directory by use of predefined labels to enforce
access rights to information stored within the Directory. User or end-entity authorization
information may be exchanged through extensions to the Version 3 X.509 certificates.
ACI about the target (data within the DIB) shall be conveyed through the use of
sensitivity labels. The format and processes associated with the privilege/authorization
information are defined within each CMI’s CPS. The format and processes associated
with security labels are defined in an Annex of ACP 120.

416. Within the Allied Directory Service there is a requirement to hold information at
different levels of protective marking, and therefore, it is necessary to have a method by
which the confidentiality of the information can be maintained without disclosure to
unauthorized access. In addition, there may be occasions where information will be
stored in a Directory that is of a higher classification than that which the DSA normally
supports, or is of a sensitive nature and requires separation from disclosure to system
administrators and other authorized users. This requirement shall be supported by one of
the following mechanisms, in accordance with security policy:

a. Encryption of the stored information to protect its content from

unauthorized disclosure;

b. Access control mechanisms to protect the stored information from

unauthorized access; and

c. Use of both services.

BASIC ACCESS CONTROL (BAC)

417. BAC is based on a relatively simple concept that either a list of users and the
permissions to which they are entitled, or a list of protected items and the permissions
necessary to access them, is held within the directory. This information is contained
within ACI items. ACI items can be held within a number of parts of the directory
depending on their intended usage and sphere of influence.

418. Each ACI item consists of four part:

a. Identification tag is used to name a particular ACI item;

b. Precedence level is a number which determines the order in which ACI

items should be considered. An item with a higher precedence will
overrule an item with a lower precedence;

4-4 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

c. Authentication level is the level to which the user must be authenticated.

This can be no authentication, simple authentication, strong
authentication, or by some external method; and

d. Either “Item first permissions” values, which list a set of protected items,
and the set of users, all potentially with varying permissions, or “User first
permissions” values, which list a set of users and the protected items, all
potentially with varying permissions that the users may or may not access.

RULE-BASED ACCESS CONTROL (RBAC)

419. Within ACP 133 and the civil standards arena, a requirement for additional
information to be included in determining whether access can be granted or denied to an
object has been identified. This is defined as RBAC and requires administratively
imposed access control policies to be applied to the contents of the directory.

420. RBAC uses security labels that can be attached (by securely binding the label to
the information using a digital signature) to attribute values stored within the directory.
The security label of an attribute shall be bound to the attribute value using a digital
signature. This label can then be used to determine whether a user may access protected
information. RBAC can be used alone, or in conjunction with BAC. Refer to clause
17.4.3 in ITU-T Rec. X.501 (1997) | ISO/IEC 9594-2: 1997.

421. RBAC adds the following constraints on the access control decision:

a. DiscloseOnError is not supported under RBAC, and hence if Read access

is denied, then the operation acts as if the entry does not exist;

b. RBAC affects operations on reading attribute values (e.g., Read and

Search) in that the attribute value is not visible if access is not authorized
(operation is carried out as though the attribute value is not present). It
does not currently affect operations on entries as a whole which do not
impact on existing attribute values (e.g., Add Entry);

c. RBAC operations which involve removing an attribute value (e.g.,

Remove Entry, Modify Entry, and Remove Attribute) fail if the access is
not authorized; and

d. If access to all attributes of an entry is denied under RBAC, access is

denied to that entry for all operations.

422. An error code is returned from an operation or the attribute value, attribute type,
or entry is omitted from the operation result if:

a. The label for the attribute value denies access, then the attribute value is
hidden;

4-5 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

b. The labels for attribute values of a given type deny access; the existence of
the attribute is hidden. (If access is denied to all attribute values of a type,
then access is denied to that type.); and

c. The labels for attribute values of a given entry deny access; the existence
of the entry is hidden. (If access is denied to all attribute values of an
entry, then access is denied to that entry.)

423. To enforce RBAC, initiator-bound access control information (clearance

information) needs to be provided to enable a comparison to be made with the target’s
security label. Clause 17.5 of ITU-T Rec. X.501(1997) | ISO/IEC 9594-2: 1997
identifies the syntactic representation for the clearance attribute. There are at least two
methods to convey this information with integrity:

a. The user's clearance can be bound to the user’s DN and the public key
used to authenticate that DN with a public key certificate extension; and

b. The user's clearance can be bound to the user’s DN and to the user’s
X.509 certificate using an attribute certificate.

424. If the first method is chosen and the authority verifying the public key
information of a user may or may not be the same authority that is responsible for issuing
and verifying a user's clearance, the clearance must be supplied to the CA in a trusted
manner.

425. Each CMI’s CPS shall include the procedures required to validate each end-
entity’s identity and privilege/authorizations.

426. The security labels will be based on a hierarchical set comprising

UNCLASSIFIED, RESTRICTED, CONFIDENTIAL, SECRET and TOP SECRET,
which can be compared to the clearance of the requester based on a corresponding set of
hierarchical class values. These hierarchical classifications form the “base set” for the
RBAC scheme and will be extended to address privilege information conveyed in a
security category and/or privilege marking.

427. In resolving permissions, the DSA shall first obtain the clearance of the user from
a trusted source. This information shall be conveyed during the authentication process.
When obtained, the contents of the security label are checked against the user’s
clearance. RBAC does not define what type of subsequent operations may be performed
e.g., modify, remove etc.

ACCESS CONTROL DECISION FUNCTION

428. In the event that RBAC has been implemented, additional steps in the access
control transforms must occur. First, the hierarchical clearance of the user must dominate
the hierarchical classification of the label. Second, if additional categories have been
applied to the security label, there must be a comparison function between the security

4-6 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

categories component of both the data label and the user clearances. If RBAC succeeds
and there are no additional RBAC restrictions imposed, the user is granted access. The
security policy rules defining the relationship between the end-entity’s
privilege/authorization set and the security label shall be provided by each nation’s
appropriate authority.

429. The Access Control Decision Function (ACDF) specifies how ACI items shall be
processed in order to determine whether access should be granted for a particular
operation.

430. Figures 4-1 and 4-2 are based on the ISO/IEC 10181-3 Security Framework in
Open Systems standard (Part 3 - access controls), but have been adapted to fit the BAC
model described in the X.500 standard. The ACDF makes the decision as to whether to
grant or deny access to the requested object(s) by applying pre-defined access control
policy rules to an access request.

Access Control
Enforcement Function
Initiator access request argument grant/deny

operation (requested
access mode &
object attributes), access decision
requestor, grant/deny Directory
authentication level
access control information
Access Control associated with the entry containing
Decision Function (or which is) the protected item

access control policy rules

Figure 4-1 – Diagram of ACDF Required for Basic Access Control

4-7 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

Access Control
Enforcement Function
Initiator access request argument grant/deny

operation (requested
access mode &
object attributes), access decision
requestor, grant/deny Directory
authentication level
and clearance access control information
Access Control associated with the entry containing
Decision Function (or which is) the protected item,
including the security label attached
to the item

access control policy rules

Figure 4-2 – Diagram of ACDF Required for Rule-based and Basic Access Control

431. If RBAC is being used in conjunction with BAC, then RBAC should always take
precedence over the BAC. Therefore, if RBAC scheme rules do not allow access to a
requested operation, then the operation will be denied independently of whether access
would have been granted under the BAC scheme. Only if the RBAC scheme rules allow
access to a requested operation will the ACDF for BAC be executed to determine if
access should be granted.

432. A policy identifier shall be used to identify under which security policy the
clearance and security labeling is being enforced.

433. The security policy is represented by an object identifier that indicates the security
policy the subject supports. Each security policy registered shall have documentation
that indicates the values of classifications and privilege/authorization sets valid within the
context of that security policy.

KEY MANAGEMENT

434. Common cryptographic algorithms and their intended usage need to be supported.
National CPS will define acceptable cryptographic algorithms and required usages.

435. In the event that a DSA’s signature or confidentiality keys are compromised,
immediate notification to the Security Authority shall occur.

CONFIDENTIALITY

436. In some situations, the Allied Directory may not give sufficient assurance that
data is kept confidential in storage, regardless of access controls. Confidentiality of
attributes in storage is provided through use of:

4-8 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

a. A template for the definition of attributes which are protected by a security

transformation which provides confidentiality. (Refer to Clause 18.2.2 of
ITU-T X.501 (1997) | ISO/IEC 9594-2: 1997.)

b. An attribute for distributing keys to those who need to decrypt attributes

using the identified key. The key being distributed is protected by
encrypting the key value with the public key of each authorized reader of
the attribute. (Refer to Clause 18.2.3 of ITU-T X.501 (1997) | ISO/IEC
9594-2: 1997.)

437. Note: Other mechanisms can be used to distribute the keys required to protect
attributes defined using the Encrypted Attribute Value template.

LABELING

GENERAL

438. A common policy on labeling and clearance is the basis for labeling in the Allied
Directory. The format and processes associated with security labels are defined in an
Annex of ACP 120. Labeling and clearance information implemented in the Allied
Directory Services shall support access control in the shared information environments.

439. Security Classification:

a. The following security classifications are valid:

• UNCLASSIFIED

• RESTRICTED

• CONFIDENTIAL

• SECRET

• TOP SECRET

b. These classifications are hierarchical and are listed in ascending order, that
is RESTRICTED is a higher classification than UNCLASSIFIED;

c. Within subject Clearances issued to end-entities, the following

classifications are valid:

4-9 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

• UNCLASSIFIED

• RESTRICTED

• CONFIDENTIAL

• SECRET

• TOP SECRET

d. These clearances are listed in hierarchical order with Top Secret

dominating Secret and so on. A Top Secret clearance allows access to all
other information unless other restrictions apply. The rules governing the
population of the clearance attribute are defined in each CMI’s certificate
policy.

440. Categories:

a. Categories may be divided into multiple groups. At a minimum, the

following types shall be supported:

• Restrictive

• Permissive

• User-Defined

b. A Restrictive Category requires that all values present in the security label
shall be present in the authorizations conveyed in the clearance;

c. Permissive Categories require that at least one value present in the security
label shall be present in the authorizations conveyed in the clearance. This
is applicable when indicating the capability to constrain access by
nationality, for example, Release To or Eyes Only;

d. User-Defined Categories shall be identified when implemented across

international boundaries; and

e. An ACDF matches the user or end-entity’s clearances and the attribute

security label to determine if the user or end-entity is allowed to access the
attribute value. The permissive categories are checked by access control
functions to ensure that if any one of the bits in the extension matches the
bits in the security label, the attribute can be accessed. The restrictive
categories are used by access control functions to ensure that all bits in the
certificate extension match all the bits in the label prior to granting access.
The user-defined categories shall process in accordance with the registered
procedures.

4-10 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

441. Privacy Markings. Privacy markings are text handling instructions and
warnings. They provide no support for access control decisions.

442. Policy Identifiers:

a. The set of the categories and classifications and their semantic

interpretation is defined in context of the policy identifier; and

b. Multiple security policies will exist and need to be supported.

Equivalency mapping will be identified through the cross certification
processes.

443. Availability. Availability of the data in the Allied Directory System shall be
ensured through robust replication and disaster recovery practices.

444. Integrity:

a. Data integrity provides proof of the integrity of the information, either in

storage or while in communications channels. The mechanism involves
encipherment of a compressed string of the relevant data to be stored or
transferred. This will be a function of the digital signature mechanisms
using an asymmetric scheme;

b. In the event integrity is required on information stored in the directory, the

information shall be signed. The user who requires validation of the
integrity of that information shall validate the signature to ensure no
unauthorized modifications have occurred. The definition of an attribute
type to hold a digital signature, along with associated control information,
which provides integrity of a whole entry or all values of selected attribute
types is found in clause 18.1.2 of ITU-T X.501 (1997) | ISO/IEC 9594-2:
1997;

c. The Allied Directory shall support integrity on a single attribute value.

The definition of the Attribute Value Integrity Information Context is
found in Clause 18.1.3 of ITU-T X.501 (1997) | ISO/IEC 9594-2: 1997;
and

d. The Allied Directory shall be capable of supporting signed operations on

all operation requests received, as well as generate signed responses to
those arguments. This shall include error responses. The integrity
protection required shall be negotiated and agreed-upon when establishing
connectivity. For those combined task force environments that cannot
support the required protection, then the information may be returned
unprotected. The decision to utilize the information is up to the policies of
the task force commander.

4-11 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

Section II - Accountability/Auditing
DATA PROTECTION

445. Any of the information that is stored within a Security Management Information
Base (SMIB) shall be protected against manipulation or destruction by unauthorized
users or end entities. Changing any of the thresholds associated with collection of audit
information shall be made available only to those authorized audit management entities.
When information from one domain is replicated into another domain, the agreement to
shadow shall contain details on how archive of and access to audit data will be supported.

4-12 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

CHAPTER 5

DIRECTORY MANAGEMENT POLICIES AND PROCEDURES

SCOPE

501. The policies defined in this document for management are applicable to the
directory system component level of the Allied Directory System. Additional
requirements such as help desks and operations relating to the higher level system issues
of the Allied Directory System will be covered in related documents.

502. There are three operational areas of management to consider:

a. Management of each nation's domain shall be performed at the national

level and is out of the scope of this document;

b. Management of a combined domain shall be performed in accordance with

this ACP and under the control of the commander of the CTF; and

c. Management of the international domain, such as the management of

Border DSAs shall be performed as defined in this ACP and other Allied
documents.

MANDATED FUNCTIONALITY

503. For the purposes of ensuring a base level of management functionality within the
Allied Directory System components, the following features and functions are mandated:

a. All DSAs and DUAs shall be capable of extending the schema to include
new object classes and attributes and (optionally) new syntaxes, without
recourse to software rework;

b. All DSAs shall be able to have ACI and other subentry information
configurable;

c. All DSAs shall be able to have their replication agreements configurable;

d. All DSAs shall support logging facilities as defined in paragraph 505;

e. All DSAs shall support, as a minimum, the X.500 Directory Monitoring

Management Information Base (MIB) defined in RFC 1567, or equivalent;

f. All DSAs shall support the generation of events or alarms and log entries
that reflect error conditions such as resource problems, protocol failures,
or system security violations. Sample alarms include:

(1) Security violations (unable to authenticate DUA-DSA or DSA-

DSA),

5-1 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

(2) Connection failure,

(3) Resource limits encountered,

(4) Process error; and

g. All DSAs shall provide a management console interface that will permit
local and remote management. Remote management facilities shall be
applied with some authorization and protection mechanism.

DESIRABLE ADDITIONAL FUNCTIONALITY

504. The following additional features and functions are desirable:

a. DUAs should be configurable by a system administrator to control the

services that are permitted to the DUA user. Note that the Allies intend to
control the extent of DAP operations by DUAs by configuring the DUA
and by access control information in the DSA;

b. Management interfaces of Directory components should apply standard

protocols such as DAP, CMIP and/or SNMP;

c. Management logs and log controls should reflect the functionality defined
in ITU-T Rec. X.735 | ISO/IEC 10164-6; and

d. Management facilities provided with directory components should relate

to directory domains, i.e., multi-DSA systems.

EVENT LOGS

505. DSAs shall provide for the logging of all operations with various levels of detail.
Log control mechanisms shall provide configuration or functions for:

a. Controlling the size of log;

b. Action taken when a file is full, e.g. overwrite the log or create a new file;

c. Deleting or archiving the log;

d. Controlling logging levels; and

e. Starting and stopping logging.

5-2 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

506. Log entries shall provide:

a. Event time;

b. Event type;

c. Operation type (e.g., List, Modify, Modify DN);

d. Originator’s DN;

e. Target object;

f. Outcome of request or response, i.e., success, failure, error, etc.; and

g. Major parameters, including:

(1) Service controls,

(2) Filter used,

(3) Security parameters, and

(4) Entry Information Selection.

507. DSAs shall support recording the following errors:

a. Errors defined in clause 12 of X.511, such as nameError, updateError,

attributeError, securityError, abandoned, abandonFailed;

b. Errors defined in clause 12 of X.525, such as shadowError. Sample

problems are unsupportedStrategy and inactiveAgreement;

c. Errors defined in clause 24 of X.501, such as operationalBindingError.

Sample problems are invalidAgreement and notAllowedForRole; and

d. Errors defined in clauses 11 - 13 of X.518, such as dsaReferral.

SERVICE LEVEL AGREEMENT (SLA)

508. An SLA is the formal agreement to be used between Allies for the operation of
an ACP 133-compliant directory. Such agreements shall be established on a bilateral
basis between Allies and shall address the quality, quantity, and, where appropriate, the
cost of the directory service to be established. An SLA shall include sufficient
definitions and measures of performance to cover the type of service, the quantity and
quality of the service required, and any time-scale targets.

5-3 Original
UNCLASSIFIED (Reverse Blank)
 UNCLASSIFIED
ACP 133(D)

CHAPTER 6
SCHEMA
Section I - Concepts
GENERAL

601. The ACP 133 schema is based as far as possible on civilian standards, in
particular, ITU-T Rec. X.402 (1995), ITU-T Rec. X.509 (2000), ITU-T Rec. X.520
(2000), ITU-T Rec. X.521 (2000) and ITU-T Rec. X.841 (2000 E). In the Allied
Directory System, all of the required object classes, attributes, matching rules, and name
forms defined in X.501, X.509, X.520 and X.521 shall be implemented, as well as
selected elements from X.402 and X.841.

602. In addition to ITU defined civilian standards, a number of directory-oriented

Internet RFCs are also used, including RFC 1274, RFC 1327, RFC 1778, RFC 1779,
RFC 2252, RFC 2253 RFC 2459, RFC 2587 and RFC 2798. References to all of these
documents are given on pages REF-1 onwards.

603. This ACP defines a “common content” which is the schema that must be
implemented by the Allied Directory System. The Common Content is split into 3
separate subsets, a Core Schema (Class A), which ALL implementations MUST fully
support, and two optional subsets, one for support of PKI (Class B), the other for support
of legacy ACP 127 messaging (Class C).

604. The primary role of the ACP 133 Schema has been redefined to prioritize
interoperability between national directory systems using one of a number of alternative
mechanisms, including DISP Replication, Meta-Directories or LDIF/XML Text files.
Key to successful interoperability is a common Schema definition, thus ensuring that a
receiving nation knows what to expect from its peer and can validate the received data
against this.

605. Each directory entry in the Allied Directory System is therefore defined by a
Structural Object Class (SOC). Attributes which can be present in the Structural Object
Class and any Auxiliary Object Classes (AOC) which can be associated with it are also
defined. It was decided not to employ the use of Content Rules in the definition of
directory entries since these were found to complicate directory replication since the
contents of exchanged entries could differ. Since Content Rules are internal to a nation
and not part of the replicated information, it is immaterial whether a nation chooses to
implement the Common Content schema internally using Content Rules or not.

606. The ACP 133(D) Schema is given in ACP 133 SUPP-1. Inclusion of auxiliary
object classes and additional attributes depends on the application, as specified in
Chapter 3. For example, an entry for an organizational unit which is used for secure
ACP 123 messaging would include the mhs-user and securePkiUser auxiliary object
classes. An organizational unit which is used for DIT navigational purposes would not
populate those classes. However, regardless of the combinations of Auxiliary Object
Classes and attributes used, the basic Schema rules must NOT be violated.

6-1 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

Section II - Common Structural Object Classes

COMMON STRUCTURAL OBJECT CLASSES

607. The Allied Common Content includes base structural object classes and structural
object classes defined in this ACP. The Allied Directory System entries defined using
these structural object classes are described in Section V of this chapter. The object
classes and attributes defined in this ACP are further split into functional groups as
follows:

a. Class A: Core International Interoperability Subset: These object

classes must be fully supported by all implementations claiming to support
this ACP;

b. Class B: Public Key Infrastructure Subset: These additional object

classes add PKI capability to the Class A Core subset and must be fully
supported by all implementations claiming to support PKI within this
ACP;

c. Class C: Legacy Messaging Subset: These additional object classes add

Legacy (ACP 127) Military Messaging capability to the Class A Core
subset and must be fully supported by all implementations claiming to
support legacy messaging within this ACP; and

d. Class D: Identity Management Subset: These additional object classes

add Identity Management capabilities.

608. The key requirement for conformance to this ACP is International

Interoperability. How a directory schema has been implemented internally to a nation is
immaterial; however conformance to agreed schema rules is critical for successful
international interoperability. Thus nations must fully support the base X.500 structural
objects plus either Class A or Classes A and B or Classes A and C or all three Classes
when sharing data internationally.

609. The following paragraphs further describe the structural object classes used in this
ACP. ACP 133 SUPP-1 provides a formal definition of them. Even the base object
classes and attributes defined in X.500 are also listed in this document for completeness.
Although great care has been taken to ensure compatibility with the base definitions,
differences will inevitably occur due to mistakes or evolving changes. In this case, the
definitions given within ACP 133 take precedence for Allied interoperability.

DIRECTORY BASE STRUCTURAL OBJECT CLASSES

610. Superclasses. Each of these base classes is used in the Common Content as a
superclass in the definition of base structural object class, as described below:

6-2 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

a. top; and

b. alias.

611. Base Object Classes. The Common Content uses only the following standard
classes as the structural object classes of Allied Directory Entries:

a. country;

b. cRLDistributionPoint;

c. device;

d. groupOfNames;

e. inetOrgPerson;

f. locality;

g. organization;

h. organizationalPerson;

i. organizationalRole;

j. organizationalUnit; and

k. person.

OTHER STANDARD STRUCTURAL OBJECT CLASSES

611. There are other standard structural object classes that are defined within X.500,
but which are not included in the Common Content, and thus may not be used to meet
Allied Directory interoperability requirements. These structural object classes have been
added for further clarification of interoperability requirements and include (but are not
limited to):

• applicationEntity
• applicationProcess
• dSA
• groupOfUniqueNames
• residentialPerson
• strongAuthenticationUser

6-3 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

DIRECTORY STANDARD OBJECT CLASS DESCRIPTIONS

612. The rest of this paragraph describes the directory standard structural object classes
that are used as base classes in directory entries in the Common Content. Descriptions
are not included for the object classes that are used solely as superclasses (e.g., top) in the
Common Content.

613. country. The country object class is used to define nation directory entries. This
object class is the base class for Country type directory entries.

614. cRLDistributionPoint. The cRLDistributionPoint object class is used in

defining directory entries for objects which act as CRL Distribution Points as defined in
ITU-T Rec. X.521 | ISO/IEC 9594-7.

615. device. The device object class is used to define entries representing devices. A
device is a physical unit which can communicate or hold information, such as a modem,
disk drive, etc. This object class is used as a superclass for the ACP 133 aCPDevice
structural object class as well as the base class for Device type directory entries.

616. groupOfNames. The groupOfNames object class is used to define directory

entries representing an unordered set of names which represent individual objects or other
groups of names. The membership of a group is static (i.e., it is explicitly modified by
administrative action, rather than dynamically determined each time the group is referred
to). The membership of a group can be reduced to a set of individual object's names by
replacing each group with its membership. This process would be carried out recursively
until all constituent group names have been eliminated, and only the names of individual
objects remain. This object class is used as a superclass for the ACP 133
aCPGroupOfNames structural object class as well as the base class for GroupOfNames
type directory entries.

617. inetOrgPerson. The inetOrgPerson object class is used to define directory

entries representing people employed by, or in some other important way associated with,
an organization. This object class is used as a superclass for the ACP 133
aCPOrganizationalPerson structural object class as well as the base class for
InetOrgPerson type directory entries.

618. locality. The locality object class is used to define directory entries that represent
places. This object class is used as a superclass for the ACP 133 aCPLocality structural
object class as well as the base class for Locality type directory entries.

619. organization. The organization object class is used to define directory entries
that represent organizations.

620. organizationalPerson. The organizationalPerson object class is used to define

directory entries representing persons within an organization. An organizational person
entry is normally related to one or more organizational roles that the person fills. Over its
lifetime, however, an organizational person entry may be related to a number of different

6-4 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

organizational roles in succession. This object class is used as a superclass for the ACP
133 aCPOrganizationalPerson structural object class as well as the base class for
OrganizationalPerson type directory entries.

621. organizationalRole. The organizationalRole object class is used to define

directory entries representing positions or roles within an organization. An
organizational role is normally considered to be filled by a particular organizational
person. Over its lifetime, however, an organizational role may be filled by a number of
different organizational persons in succession. In general, an organizational role may be
filled by a person or a non-human entity. This object class is used as a superclass for the
ACP 133 aCPOrganizationalRole structural object class as well as the base class for
OrganizationalRole type directory entries.

622. organizationalUnit. The organizationalUnit object class is used to define

directory entries representing subdivisions of organizations. This object class is used as a
superclass for the ACP 133 aCPOrganizationalUnit structural object class as well as the
base class for OrganizationalUnit type directory entries.

623. person. The person object class is used to define directory entries representing a
person. This object class is used as the base class for Person type directory entries.

6-5 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

Section III - Directory System Schema

GENERAL

624. This subsection lists the information required for the Directory to know how to
operate correctly. It specifies the type of information that is required in the Directory
System Schema. The Directory System Schema consists of:

a. A definition of subentry object classes; and

b. A definition of Directory operational attributes.

625. The Directory System Schema is distributed. Each administrative authority

establishes the part of the system schema that will apply for those portions of the DIB
administered by the authority. Each DSA participating in a directory system requires a
full knowledge of the system schema established by its administrative authority. The
Directory System Schema is not regulated by DIT structure or content rules and is
normally viewed and controlled by the Directory Administrator, or the DSA itself.

626. It should be noted that this section is only relevant where DISP replication or DSP
chaining and referrals are being performed internationally. If other forms of replication
or directory access are being used, or if the directory system does not span national
boundaries, the information given here is informational and advisory only. Nations do
not have to adhere fully to it.

627. Standard Subentry Object Classes. The following subentry object classes are
defined by X.501 and shall be supported by the ACP 133 Directory:

a. The subentry object class supports the Administrative and Operational

Information Model of the Directory. The subentry object class is used to
define the name and subtree for an access control, collective attribute, or
subschema subentry of an administrative point;

b. The accessControlSubentry object class contains precisely one

prescriptive Access Control Information attribute which contains access
control information applicable to directory entries within that subentry’s
scope;

c. The collectiveAttributeSubentry shall contain at least one collective

attribute which is available for interrogation and filtering at every entry
within the scope of the subentry’s Subtree Specification attribute; and

d. The subschema object class is used to contain the operational attributes

that represent the policy parameters used to express subschema policies
(schema publication). The attributes include the rules and constraints
concerning DIT structure, DIT content, object classes and attribute types,
syntaxes, and matching rules which characterize the DIB.

6-6 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

STANDARD OPERATIONAL ATTRIBUTES

628. Operational attributes defined by X.500 and cited in this paragraph shall be
supported by the ACP 133 Directory. The definition of an operational attribute includes
a specification of the way in which the Directory uses and manages the attribute in the
course of its operation. There are two varieties of operational attribute:

a. Directory operational attributes; and

b. DSA Specific Entry (DSE) operational attributes.

629. Directory operational attributes occur in the Directory information model and are
used to represent control information or other information provided by the Directory.
DSE operational attributes are further categorized into two:

a. DSA-shared operational attributes; and

b. DSA-specific operational attributes.

630. They occur only in the DSA information model and are not visible at all in the
Directory Information model.

DIRECTORY OPERATIONAL ATTRIBUTES

631. The subtreeSpecification attribute shall be supported by the ACP 133 Directory.
It supports the administrative and operational information model and is used to specify
the scope of a subentry or area of replication. It is also used to regulate the subentries
permitted to be subordinate to an administrative entry such as access control or collective
attribute subentries.

632. The administrativeRole attribute shall be supported by the ACP 133 Directory. It
supports the administrative model and is used to indicate the role or roles of an
administrative entry. The attribute may be stored in one or more of the following
administrative points:

a. Autonomous Administrative Point;

b. Access Control Administrative Point;

c. Access Control Inner Administrative Point;

d. Subschema Administrative Point;

e. Collective Attribute Administrative Point; and

f. Collective Attribute Inner Administrative Point.

6-7 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

633. The attributes below, which may be contained in an entry or subentry, support
general administrative and operational requirements. These attributes shall be supported
by the ACP 133 Directory. All DSAs which conform to this ACP shall automatically
provide date/time of creation/modification and creators/modifiers name on directory add
and modify operations:

a. createTimestamp. The createTimestamp attribute is required for

replication;

b. modifyTimestamp. The modifyTimestamp attribute is required for

replication;

c. creatorsName. The creatorsName attribute is desirable for audit

purposes; and

d. modifiersName. The modifiersName attribute is desirable for audit

purposes.

634. The collectiveExclusions attribute allows particular collective attributes to be

excluded from an entry and shall be supported.

635. The following attributes are used by the Security Model of the Directory and shall
be supported:

a. accessControlScheme. The accessControlScheme attribute indicates

which access control model, such as Basic Access Control or Simplified
Access Control, is in effect for an administrative area. It is placed in the
Administrative Entry for the corresponding Administrative Point;

b. prescriptiveACI (Basic or Simplified Access Control). The

prescriptiveACI attribute is contained in an access control subentry;

c. entryACI (Basic Access Control). The entryACI attribute,which may be

used in Basic Access Control, is an operational attribute of an entry or
subentry and contains access control information applicable to that entry;
and

d. subentryACI (Basic or Simplified Access Control). The subentryACI

attribute is used in an administrative entry to provide access control
information for subentries of the administrative point.

DSA SPECIFIC ENTRY (DSE) OPERATIONAL ATTRIBUTES

636. Each directory entry in the DSA also contains additional attributes beyond those
that are visible to Directory administrator. The following attributes are operational
attributes contained in DSEs. These attributes are used by the DSA Information Model
and shall be supported by the ACP 133 Directory:

6-8 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

a. dseType. The dseType indicates the role or roles of a DSE, such as entry,
subentry, or administrative point;

b. myAccessPoint. The myAccessPoint attribute is an operational attribute

used to represent its own access point and is contained in the root DSE.
The information may be used by the DOP when establishing or modifying
an operational binding;

c. superiorKnowledge. The superiorKnowledge attribute is used by the

DSA to find access points of DSAs for a naming context;

d. specificKnowledge. The specificKnowledge attribute is used by the DSA

to find access points of DSAs for a naming context;

e. nonSpecificKnowledge. The nonspecificKnowledge attribute is used by

the DSA to find access points of DSAs for a naming context;

f. supplierKnowledge. The supplierKnowledge attribute is used by the

DSA to know the access points and shadowing agreement identifiers of a
replicated area. It is managed by the DSA itself;

g. consumerKnowledge. The consumerKnowledge attribute is used by the

DSA to know the access points and shadowing agreement identifiers of a
replicated area. It is managed by the DSA itself; and

h. secondaryShadows. The secondaryShadows attribute is managed by the

DSA itself and contains access points of consumer DSAs which are
engaged in secondary shadowing.

637. A DSE may have only user attributes, operational attributes or both depending on
its role within the total DIB. Therefore, to identify an entry with its role and DIB
location and its effect in the scheme of the total (and possibly distributed and replicated)
DIB, a number of DSE entry types have been defined. Table 6-6 defines the standard
DSE types and their purpose. The DSE types shall be supported by this ACP for all
DSAs in accordance with their definition.

RULES FOR DIT SCHEMA MANAGEMENT

638. The following attributes specify the subschema policy and are contained in the
subschema subentry and shall be supported:

a. dITContentRules;

b. dITStructureRules;

c. matchingRules;

d. attributeTypes;

6-9 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

e. objectClasses;

f. nameForms;

g. matchingRuleUse;

h. structuralObjectClass; and

i. governingStructureRule.

6-10 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

DSE Type Purpose

root Is the root of the DSA Information Tree.
glue Represents knowledge of a name only. Used to connect the fragments
of a DIT in shadowed copies, for example.
cp Is the context prefix of a naming context, the root of a subtree.
entry Holds an object entry, user information.
alias Holds an alias entry.
subr Holds a reference to a DSA holding a portion of the DIT subordinate to
that in this DSA. Contains the context prefix of the subordinate.
nssr Holds a non-specific subordinate reference to a DSA that holds some
subordinate that is not named.
supr Holds a superior reference, a DSA which holds a naming context
superior in the DIT to all the naming contexts held by this DSA.
xr Holds a cross reference to another DSA, used for optimization. Points
directly to a remote naming context.
admpoint Is an administrative point, the root vertex of an administrative area, a
subtree of the DIT whose entries are all administered by the same
Administrative Authority.
subentry A subentry that is located under an administrative point and contains
policy for access control, schema, and collective attributes.
shadow Holds a shadow copy of an entry or part of an entry. Set by the
shadow consumer.
immSupr Holds a reference to a naming context immediately superior to the
referencing one.
rhob Holds information about a superior administrative point or subentry
passed by a Relevant Hierarchical Operational Binding between DSAs.
sa Subordinate reference DSE points to an alias entry.

Table 6-1 - DSE Types and Their Purpose

6-11 Original
UNCLASSIFIED (Reverse Blank)
 UNCLASSIFIED
ACP 133(D)

REFERENCES

REF TITLE
ACP 120: Information Technology - Defense Standardized Profiles AMHxn(D) -
Message Handling Systems - Message Security Protocol - Part 3:
AMHx2(D) - MSP Requirements for Message Transfer (P1).
ACP 133: Common Directory Services and Procedures Edition C.
E.123: ITU-T Rec. E.123 (1988): Notation for national and international
telephone numbers.
ISO 3166: ISO 3166 – 1981: Codes for the representation of names of countries.
JFIF: JPEG File Interchange Format (Version 1.02). September 1992.
SDN.700: MCCB-04.02.013. Registration Procedures for Technical Objects
(INFOSEC Arc). Revision 1. 7 February 1997.
RFC 1274: Internet RFC 1274 (Nov 1991): The COSINE and Internet X.500
Schema.
RFC 1327: Internet RFC 1327 (May 1992): Mapping between X.400 (1988) / ISO
10021 and RFC 822.
RFC 1778: Internet RFC 1778 (Mar 1995): The String Representation of Standard
Attribute Syntaxes.
RFC 1779: Internet RFC 1779 (Mar 1995): A String Representation of
Distinguished Names.
RFC 1960: Internet RFC 1960 (June 1996): A String Representation of LDAP
Search Filters.
RFC 2079: Internet RFC 2079 (Jan 1997): Definition of an X.500 Attribute Type
and an Object Class to Hold Uniform Resource Identifiers (URIs).
RFC 2252: Internet RFC 2252 (Dec 1997): Lightweight Directory Access
Protocol (v3): Attribute Syntax Definitions.
RFC 2253: Internet RFC 2253 (Dec 1997): Lightweight Directory Access
Protocol (v3): UTF-8 String Representation of Distinguished Names.
RFC 2255: Internet RFC 2255 (Dec 1997): The LDAP URL Format.
RFC 2256: Internet RFC 2256 (Dec 1997): A Summary of the X.500 (96) User
Schema for use with LDAP v3.
RFC 2459: Internet RFC 2459 (January 1999): Internet X.509 Public Key
Infrastructure Certificate and CRL Profile.
RFC 2587: Internet RFC 2587 (June 1999): Internet X.509 Public Key
Infrastructure LDAPv2 Schema.

REF-1 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

REF TITLE
RFC 2798: Internet RFC 2798 (Apr 2000): Definition of the iNetOrgPerson
LDAP Object Class.
RFC 2822 Internet RFC 2822 (April2001): Internet Message Format
RFC 2849: Internet RFC 2849 (June 2000): The LDAP Data Interchange Format
(LDIF) – Technical Specification.
RFC 3384: Internet RFC 3384 (October 2002): Lightweight Directory Access
Protocol (version 3) Replication Requirements.
RFC 4122: Internet RFC 4122 (July 2005): A Universally Unique IDentifier
(UUID) URN Namespace.
X.208: ITU Rec. X.208 (1993): Open Systems Interconnection Model and
Notation – Specification of Abstract Syntax Notation One.
X.501 ITU Rec. X.501 (2005): Information Technology – Open systems
interconnection – The directory: Models
X.509: ITU-T Rec. X.509 (2000) | ISO/IEC 9594-8:2000 Information
Technology – Open Systems Interconnection – The Directory: Public-
Key and Attribute Certificate Frameworks.
X.520: ITU-T Rec. X.520 (2000) | ISO/IEC 9594-6:2000, Information
Technology – Open Systems Interconnection – The Directory: Selected
Attribute Types.
X.521: ITU-T Rec. X.521 (2000) | ISO/IEC 9594-7:2000, Information
Technology – Open Systems Interconnection – The Directory: Selected
Object Classes.
X.402: ITU-T Rec. X.402 (1995) | ISO/IEC 10021-2: 1996 Information
technology – Message Handling Systems (MHS): Overall architecture
Annex A: Directory Object Classes and Attributes.
X.841: ITU-T Rec. X.841 (2001 E) | ISO/IEC 15816:2001(E): Information
Technology – Security Techniques – Security Information Objects for
Access Control.

REF-2 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

GLOSSARY
The following Definitions, abbreviations and acronyms are used in this ACP:
Definitions

Address List. An Address List is a shorthand method for addressing a

predetermined list of recipients.
Administrative DUA. An Administrative DUA (ADUA) is a DUA which is used by
managers and administrators to query and modify user and
system information in the Directory in order to manage the
service and administer the information in the DIB.
Allied Directory The Allied Directory Service is a capability provided to allied
Service. forces to support a variety of information exchange
requirements. This service is implemented by the
interconnection of national and CTF directory system assets
which conform to this ACP.
Allied Directory The Allied Directory System consists of the components,
System. protocols, administrators and information that provide the Allied
Directory Service.
Border DSA. A Border DSA is a DSA that has been designated by a DMD to
provide the primary international interface for a nation’s or a
CTF’s Directory System to the rest of the Allied Directory
System.
Combined Task A CTF is a coalition of forces contributed by two or more
Force. nations for a specific operation and period of time.
Common Content. The Common Content is the collection of definitions and rules
about the Allied Directory System contents. It is the Allied
Directory System’s Directory Schema.
Interrogation DUA. An interrogation DUA uses the read, compare, abandon, list and
search operations to query user information. It has no capability
for updating or deleting directory information.
Interrogation/Modific An interrogation/modification DUA uses all of the Directory
ation DUA. Services to query and modify user information.
National DSA. A National DSA is an “internal” DSA in a national,
organizational or CTF DMD that interfaces to the Allied
Directory System through a Border DSA.
Plain Language A Plain Language Address (PLA) is an abbreviated or non-
Address. abbreviated activity (organization) title with its associated
geographical location.

Glossary-1 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

Population. Population refers to the directory entries and attributes for which
values have been entered in the Allied Directory.
Schema Support. Support for a schema element means that it can be generated,
processed, and displayed in accordance with its definition.

Glossary-2 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

Acronyms

ACRONYM DEFINITION
ACDF Access Control Decision Function
ACI Access Control Information
ACP Allied Communication Publication
ACSE Association Control Service Element
ADUA Administrative Directory User Agent
ADY 1993 Directory Application Profile
AIG Address Indicator Group
AL Address List
AMH Allied Message Handling
APP Allied Publications Procedures
ASCII American Standard Code for Information Interchange
ASN.1 Abstract Syntax Notation One
AU, AUS Australia
AUTODIN Automatic Digital Network
BAC Basic Access Control
C Country
CA Canada; Certification Authority
CAN Canada
CAD Collective Address Designator
CCEB Combined Communications Electronics Board
CCITT The International Telegraph and Telephone Consultative Committee
CMI Certificate Management Infrastructure
CMIP Common Management Information Protocol
CN Common Name
CONOPS Concept of Operations
COSINE Organization for Cooperation for OSI Networking in Europe
COTS Commercial Off-the-Shelf
CPS Certificate Practice Statement
CRL Certificate Revocation List

Glossary-3 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

ACRONYM DEFINITION
CSP Common Security Protocol
CTF Combined Task Force
CULR Common Upper Layer Requirements
DAG DSSCS Address Group
DAP Directory Access Protocol
DFTS Defense Fixed Telecommunications Service
DIB Directory Information Base
DISP Directory Information Shadowing Protocol
DIT Directory Information Tree
DL Distribution List
DMD Directory Management Domain
DN Distinguished Name
DODAAC Department of Defense Activity Accounting Code
DOP Directory Operational Binding Management Protocol
DSA Directory System Agent
DSE DSA-specific entry
DSN Defense Switched Network
DSP Directory System Protocol
DSSCS Defense Special Security Communications System
DUA Directory User Agent
EDI Electronic Data Interchange
EIT Encoded Information Type
E-MAIL Electronic Mail
EOS Elements of Service
FDY 1993 Directory Interchange Format and Representation Profile
FLDSA First-level DSA
G3 Group 3 Facsimile
G4 Group 4 Facsimile
GBR Great Britain
GENSER General Service

Glossary-4 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

ACRONYM DEFINITION
GHP Gateway Handling Policy
HOB Hierarchical Operational Binding
HQ Headquarters
IA5 International Alphabet Number 5
IBAC Identity-based Access Control
IC Intelligence Community
IEC International Electrotechnical Commission
ILS Integrated Logistics Support
ISDN Integrated Services Digital Network
ISME International Subject Matter Experts
ISO International Organization for Standardization
ISP International Standardized Profile
ITU-T International Telecommunication Union-Telecommunication
Standardization Sector
JANAP Joint Army, Navy, Air Force Procedure
L Locality
LCC Local Control Center
LEP List of Effective Pages
LMF Language and Media Format
LOP Letter of Promulgation
MCS Message Conversion System
MHS Message Handling System
MIB Management Information Base
MLA Mail List Agent
MMHS Military Message Handling System
MMUA Military Messaging User Agent
MS Message Store
MTA Message Transfer Agent
MTBF Mean Time Before Failure
MTS Message Transfer System

Glossary-5 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

ACRONYM DEFINITION
MTTR Mean Time to Repair
NASIS NATO Subject Indicator System
NATO North Atlantic Treaty Organization
NAVCOMPARS Naval Communications Processing and Routing System
NZ, NZL New Zealand
O/R, OR Originator/Recipient
O Organization
OSI Open Systems Interconnection
OU Organizational Unit
P2 Interpersonal Messaging - 1984 Content Type
P22 Interpersonal Messaging - 1988 Content Type
P772 Military Messaging Content Type
PACOM Pacific Command
PICS Protocol Implementation Conformance Statement
PKI Public Key Infrastructure
PLA Plain Language Address
PRB Project Review Board
PRMD Private Management Domain
PSTN Public Switched Telephone Network
R GENSER Community
RAN Release Authority Name
RBAC Rule-Based Access Control
RDN Relative Distinguished Name
RFC Request for Comments
RHOB Relevant Hierarchical Operational Binding
RI Routing Indicator
ROSE Remote Operations Service Element
RTSE Reliable Transfer Service Element
S/MIME Secure/Multimedia Internet Mail Extensions

Glossary-6 Original
UNCLASSIFIED
 UNCLASSIFIED
ACP 133(D)

ACRONYM DEFINITION
SA Signal Address
SAC Simplified Access Control
SDN Secure Data Network
SHD Special Handling Designator
SI Special Intelligence
SIC Subject Indicator Code
SIGAD SIGINT Address
SIGINT Signal Intelligence
SLA Service Level Agreement
SMIB Security Management Information Base
SMA Signal Message Address
SMTP Simple Mail Transfer Protocol
SNMP Simple Network Management Protocol
STANAG Standardization Agreement
STU Secure Telephone Unit
TARE Telegraph Automatic Relay Equipment
TCC Transmission Control Code
TCCG Transmission Control Code Group
TR Technical Report
TRC Transmission Release Code
TSGCE Tri-Service Group of Communications and Electronics
UA User Agent
UK United Kingdom
UKM User Key Material
US, USA United States of America
USMCEB United States Military Communications-Electronics Board
UTC Universal Coordinated Time
Y SI Community

Glossary-7 Original
UNCLASSIFIED (Reverse Blank)
 UNCLASSIFIED
ACP 133(D)

LIST OF EFECTIVE PAGES

Subject Matter Page Numbers

Title Page ....................................... i (rb)
Foreword ........................................ iii (rb)
Letter of Promulgation................... v (rb)
Record of Message Corrections..... vii (rb)
Table of Contents........................... ix to xii
List of Figures and Tables ............. xii
Chapter 1 ........................................ 1-1 to 1-6
Chapter 2 ........................................ 2-1 to 2-22
Chapter 3 ........................................ 3-1 to 3-17 (rb)
Chapter 4 ........................................ 4-1 to 4-12
Chapter 5 ........................................ 5-1 to 5-3 (rb)
Chapter 6 ........................................ 6-1 to 6-11 (rb)
References...................................... REF-1 to REF-2
Glossary ......................................... Glossary-1 to
Glossary-7 (rb)
List of Effective Pages ................... LEP-1 (rb)
rb = Reverse Blank

LEP-1 Original
UNCLASSIFIED (Reverse Blank)