Messaging and Directory Server software used around the world in the Government, Military, Aviation and Commercial sectors.

Whitepapers

ACP 133: The Military Directory Standard

 

ACP 133 is the NATO Standard for Military Directory: "Common Directory Services and Procedures". The current version is "Edition B", published in February 2000. "Edition C" is being developed, and is expected to be published shortly. This white paper gives a short summary of ACP 133 aimed at readers with some familiarity with directory services. For a general introduction to directory services see Why Deploy an Enterprise Directory. The paper explains how ACP 133 uses and extends the core standards.

What is ACP 133 used for?

The ACP 133 directory is designed as general purpose infrastructure that can hold information for a range of purposes, on roles, end users, organizations and other object. Specific functions for which this directory technology is intended and widely used are:

• Support of ACP 123 and STANAG 4406 Military Messaging.
• Support of (legacy) ACP 127 Military Messaging.
• Support of user identification for authentication purposes.
• Storage of X.509 PKI information.
• A general purpose information lookup (white pages) service.

Services and Protocols

ACP 133 uses the ITU X.500 directory standards. It does not specify any additional protocols or services. An ACP 133 directory is an X.500 directory. ACP 133 deployments often make use of advanced X.500 functionality, in particular:

• Replication. The general approach is to place all information needed in the local directory, to minimize dependencies on other servers. This means that extensive use is made of X.500 replication. For further information see: The Case for X.500 DISP.
• Strong Authentication. Avoiding passwords and use of strong authentication based on X.509 PKI is often important. For further information see: Why Strong Authentication for Directory?.
• Signed Operations are used for increased security. For further information see: Directory Signed Operations.

ACP 133 Schema

ACP 133 defines the types of information that must and may be supported ("schema"). ACP 133 includes over 40 different object types and over 160 associated attributes. The majority of this schema is defined by reference to other standards, as well as military schema defined by ACP 133.

The ACP 133 schema requires support for a number of attribute syntaxes for structured attributes that go beyond the core X.500. In order to conform to ACP 133, most directory client and server products will need to have information on these attribute syntaxes "built in". This means that although an ACP 133 directory uses only standard X.500 protocols and services, an ACP 133 directory will generally have ACP 133 specific functionality in order to support the schema.

This section gives a brief overview of ACP 133 Schema.

Incorporated Schema

ACP 133 makes maximum use of other standards, and only defines its own schema where appropriate standards do not exist. The key referenced standards are:

• X.500. Many core objects and associated attributes, such as Country, Organization, Role, Alias and Person are defined as a part of the X.500 directory standard. ACP 133 uses a wide selection of these.
• X.509. X.509, the specification for Public Key Infrastructure (PKI), defines a number of directory attributes such as Certificate, Attribute Certificate and Certificate Revocation List that are used by ACP 133 to support PKI based security functionality.
• X.400. STANAG 4406 military messaging is based on X.400 messaging. X.400 defines directory schema to enable use of X.500 directory in the X.402 standard. ACP 133 makes use of this schema to support recipient addressing, address lists, messaging capabilities and related functionality.
• X.841. X.841 defines security labels; ACP 133 uses the Security Clearance X.500 schema definition.
• SDN 801. Attributes for Security Policy are taken from this specification.

Military Generic Extensions

X.500 provides two mechanisms (auxiliary object class, and attribute sets) that allow a set of military attributes to extend other objects. These are:

• ACP Date Attribute Set: To specify period of validity for an entry.
• ACP Distribution Codes Handled: Military messages are often processed on the basis of "distribution codes". This auxiliary object class enables specification as to which distribution codes are handled by an object.
• ACP Functional Description: Additional military oriented description of an object.
• ACP MHS Capabilities Information: Attributes related to end user support of STANAG 4406 military message.
• ACP Other Contact Information: Additional contact information for military users.
• ACP Secure PKI User: Attributes to support users of X.509 PKI.
• Three auxiliary object classed used to support (legacy) ACP 127 military messaging:
  • ACP Plain Language Address ACP 127
  • ACP Plain Language Address Data
  • ACP PLA User

Military Extensions to Standard Objects

ACP 133 extends a number of standard objects, by defining ACP 133 variants of the object classes, which extend the standard X.500 object classes by adding additional military attributes, primarily using the generic attribute groups defined in the previous section. These are:

• ACP Device Entry.
• ACP Group of Names Entry
• ACP Locality Entry
• ACP Organization Entry
• ACP Organizational Person Entry
• ACP Organizational Role Entry
• ACP Organizational Unit Entry
• ACP CRL Distribution Point Entry

ACP 133 also defines two alias object classes, which extend the basic X.500 alias mechanism by enabling ACP 133 data to be held in the alias entry, as well as in the entry pointed to.

• ACP Alias Common Name Entry
• ACP Alias Organizational Unit Entry.

New Military Objects

Finally, ACP 133 defines a number of new objects.

• ACP Address List Entry: This is an entry for storing address lists to support list expansion by STANAG 4406 MLAs (Mailing List Agents). It uses many of the attributes from an X.402 defined X.400 distribution list as well as military specific attributes.
• ACP Distribution Code Description Entry: This is a directory entry designed to hold distribution codes, which enables directory based management of distribution codes.
• There are a number of objects defined to support ACP 127 messaging. These are:
  • ACP Alternate Spelling ACP 127 Entry
  • ACP Collective Address Designator ACP 127 Entry
  • ACP DSSCS PLA Entry
  • ACP Organization ACP 127 Entry
  • ACP Plain Language Address Collective ACP 127 Entry
  • ACP Routing Indicator Entry
  • ACP Signal Intelligence Plain Language Address Entry
  • ACP Special Intelligence Plain Language Address Entry
  • ACP Special Products Distribution List Entry
  • ACP Task Force ACP 127 Entry
  • ACP Tenant ACP 127 Entry

LDAP and ACP 133

LDAP is not a part of the current ACP 133 specification, although most ACP 133 products support LDAP and most ACP 133 deployments make some use of LDAP. The next update to ACP 133 ("edition C") will include guidelines for using LDAP with an ACP 133 directory.

LDAP is effective for accessing human readable information in an ACP 133 directory, but works less well for handling structured attributes, that are used extensively. The nature of the problem is best illustrated by example. Consider the DLSubmitPermissions attribute, that is used to control who can send to a distribution list. The X.500 definition is provided in X.402 as:

DLSubmitPermission ::= CHOICE {
individual [0] ORName,
member-of-dl [1] ORName,
pattern-match [2] ORNamePattern,
member-of-group [3] Name
}

This X.500 attribute syntax is clear and generally supported by ACP 133 directories. To support this in LDAP, a string representation is needed. There are two published specifications:

• CCEB 1008, which is a military document specifying how to use LDAP with ACP 133. An example value is:

  "member-of-dl=/S=Kille/G=Steve/O=Isode/PRMD=Isode/ADMD=X
  /C=GB/|CN=Steve Kille, O=Isode, C=GB"

• RFC 1778. The same example would be represented as:

  "dl_member:X400:/S=Kille/G=Steve/O=Isode/PRMD=Isode/ADMD=X
  /C=GB/#X500:CN=Steve Kille, O=Isode, C=GB"

Several vendor implementations are not aligned to either of these standards. For example, Isode R11 would use:

"MEMBER#CN=Steve Kille, O=Isode, C=GB $/S=Kille/G=Steve/O=Isode/PRMD=Isode/ADMD=X/C=GB/"

ACP 133 Edition C is expected to use the RFC 1778 syntax.

This situation is viable for a simple read only client that simply displays the string to the user. It is awkward for applications that need to edit or interpret the values. One MLA application we know of uses heuristics to work out which vendor syntax is being used.

The best advice for ACP 133 applications is to use X.500 DAP for applications that modify or need to interpret structured attributes. LDAP is a good choice for applications that read only basic attributes and do not need signed operations.