Scenarios for use of LDAP Directory in support of AMHSACP/WGN and SGN3 meetings (Montreal, May 2004)

ACP WGN03-IP02

ACP/SGN3 WP/2-5

17/05/04

AERONAUTICAL COMMUNICATIONS PANEL(ACP)

Working Group N - NETWORKING

SUBGROUP N3 – GROUND-GROUND Applications

Montréal, May 2004 (SGN3 second meeting, WGN third meeting)

Agenda Item 3 : ATS Message Handling Services

Scenarios for use of LDAP Directory in support of AMHS

Presented by Jean-Marc Vacher

Summary

In the Bangkok ACP WGN/2 meeting, it was agreed to progress the study of LDAP in support of AMHS, in addition or as a substitute for ATN X.500 Directory Services. The meeting concluded that potential benefits and constraints should be analyzed more in-depth, and that detailed specifications for the use of LDAP Directory in support of AMHS should be developed, including appropriate provisions to ensure interoperability between ATN Directory and LDAP.

The goal of this paper is to progress this analysis by the definition of scenarios for use of LDAP, thereby enabling to determine the benefits and limits of applicability of LDAP directory services in support of AMHS.

TABLE OF CONTENTS

1Introduction

2LDAP architectures

2.1LDAP used as a protocol for accessing an X.500 directory

2.2LDAP used with its own directory database

3Scenarios for use of LDAP in the ATN/AMHS context

3.1General aspects

3.1.1Scenarios

3.1.2Limits of LDAP

3.2Scenario 1: LDAP access to the ATN/AMHS Directory

3.3Scenario 2: “LDAP version” of the ATN/AMHS directory

3.4Scenario 2a: LDAP Directory in support of AMHS address conversion

3.4.1Description and assessment

3.4.2Initial study

3.5Summary of scenario presentation

4Future work

5Recommendations to the meeting

6APPENDIX A: PROTOTYPE SPECIFICATION OF SCENARIO 2A

6.1DIT structure

6.2Additional schema elements

6.3Associated conversion algorithm

REFERENCES

[1]Manual of Technical Provisions for the Aeronautical Telecommunication Network (ATN), ICAO Doc 9705, Third Edition - Sub-Volume III, Ground-Ground Applications

[2]Manual of Technical Provisions for the Aeronautical Telecommunication Network (ATN), ICAO Doc 9705, Third Edition - Sub-Volume VII, ATN Directory Services

[3]Comprehensive ATN Manual (CAMAL), ICAO Doc 9739, Second Edition

[4]RFC3377 Lightweight Directory Access Protocol (v3): Technical Specification

[5]RFC2251 Lightweight Directory Access Protocol (v3)

[6]RFC2252 Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions

[7]RFC2253 Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names

[8]RFC2254 The String Representation of LDAP Search Filters

[9]RFC2255 The LDAP URL Format

[10]RFC2256 A Summary of the X.500(96) User Schema for use with LDAPv3

[11]RFC2829 Authentication Methods for LDAP

[12]RFC2830 Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security

[13]Use of LDAP Directory in support of AMHS, ACP WGN02-WP17 (Bangkok, November 2003)

1Introduction

The ACP Working Group N has been tasked by the ANC to consider the use of TCP/IP protocols in the provision of aeronautical internetworking.

The Lightweight Directory Access Protocol (LDAP) is a protocol standardized by the Internet Engineering Task Force, which is part of the “TCP/IP protocol suite”, and supports directory services.

In the Bangkok ACP WGN/2 meeting, it was agreed to progress the study of LDAP in support of AMHS, in addition or as a substitute for ATN X.500 Directory Services. The meeting concluded that potential benefits and constraints should be analyzed more in-depth, and that detailed specifications for the use of LDAP Directory in support of AMHS should be developed, including appropriate provisions to ensure interoperability between ATN Directory and LDAP.

The goal of this paper is to progress this analysis and determine the benefits and limits of applicability of LDAP directory services in support of AMHS.

2LDAP architectures

LDAP is a client-server architecture which can be used in two different ways:

  • as a protocol to access an X.500 directory. In this case the LDAP server is limited to a “protocol gateway” server converting LDAP requests submitted by an LDAP client into X.500 requests, and vice-versa for the results. This way of working was the only available scenario with LDAPv2;
  • as a “stand-alone” implementation including its own Directory Information Base, without the use of an X.500 directory. This change in LDAP architecture was introduced with LDAPv3, while maintaining the above described LDAPv2 capability of querying an X.500 directory server. It may be considered that a “fully functional” LDAP server corresponds to this way of working.

These two architectures are depicted in the figure below.

2.1LDAP used as a protocol for accessing an X.500 directory

The simplification created by LDAP was introduced in [1]. It is based on the following aspects:

  • it relies directly upon TCP/IP lower layers, without use of OSI presentation and session layers (nor of course of OSI or ATN lower layers);
  • it offers a more limited number of directory operations than the X.500 DAP protocol. In particular the read and list X.500 operations are not defined in LDAP, but the same function can be achieved by means of a LDAP search operation;
  • it simplifies the syntax and encoding of these operations, by using a string representation for all attribute types, values and distinguished names. It should be noted, however, that the protocol is defined in ASN.1 and encoded in binary.

A result of this approach is that the vast of majority of the elements that will be transmitted by means of LDAP operations will be encoded as strings, and will be directly user-readable, to the largest possible extent.

These elements are the reason for the term “Lightweight”. One of the goals of this simplification was to limit the tasks to be performed by an LDAP client which is running on an individual work station (e.g. a PC) which, at the time of specifying LDAP, was limited in computing power. Such considerations do not apply any more, but the LDAP specification has been widely adopted by implementers, whilst X.500 DAP was not as successful.

2.2LDAP used with its own directory database

With the introduction of LDAPv3, there is no more the requirement for an X.500 Directory Server (DSA), or a network of DSAs, to hold the Directory Information Base. This information can be stored directly in a LDAP database.

RFC2256 (see [10]) defines a schema for use with LDAPv3 which includes the components of a X.500(96) user schema. RFC2252 (see [6]) provides a framework for developing Schemas for directories accessible via the LDAP. A Schema is the collection of attribute type definitions, object class definitions and other information which a server uses to determine how to match a filter or attribute value assertion (in a compare operation) against the attributes of an entry.

The specifications of these RFCs are developed in Backus-Naur Form (BNF) syntax. RFC2256 enables a LDAP server to hold the same information as a “native” X.500 directory, but without making use of the X.500 ASN.1 syntaxes for object-classes (OCs) and attribute-types (ATs). RFC2252 allows an implementer to extend the general schema offered by X.500 to include additional OCs and ATs.

In addition to the schema extensions mentioned above, LDAPv3 provides further extensibility by making possible the addition of new syntaxes, matching rules and also the addition of new operations (or the extension of existing ones).

The LDAP Directory Information Base is then accessed by the protocol defined in LDAPv2 and already described in section 2.1 above.

3Scenarios for use of LDAP in the ATN/AMHS context

3.1General aspects

3.1.1Scenarios

This section analyzes how the LDAP architecture options described in section 2.1 and 2.2 could be used in the AMHS context.

Two scenarios can be envisaged, in line with these architecture options:

  • Scenario 1: LDAP access to the ATN/AMHS directory;
  • Scenario 2: “LDAP version” of the ATN/AMHS directory.

They are depicted in the figure below.

A variant of the second scenario is also proposed as Scenario 2a.

3.1.2Limits of LDAP

The main limitation of LDAP in the ATN/AMHS context results from the limited support of ASN.1 structures, and from the use of BNF for a stand-alone LDAP server.

LDAP provides a “binary option” which allows to define attribute types. This results in conveying as a binary-encoded attribute values. In this case the OCTET STRING for the attribute value is the BER-encoding of the attribute ASN.1 syntax. This option allows to convey with LDAP complex attribute values such as X.509 certificates or X.402 OR-addresses.

3.2Scenario 1: LDAP access to the ATN/AMHS Directory

In this scenario, the X.500-based ATN Directory is used as the Directory database. The schema is the ATN schema, which combines OCs and ATs from the following sources:

  • the X.500 standards (more accurately X.520, X.521 and X.509),
  • the X.402 standard (Appendix A) for standard MHS-related information, and
  • specific ATN-defined OCs and ATs, including those necessary for AMHS.

LDAP is in this scenario an alternative to the DAP profiles specified in Document 9705 Sub-Volume 7 (Part 2).

If the ATN Directory Server is implemented for national use, or within a given AMHS Management Domain, this scenario may be seen as a local implementation scenario. As such, there is no need for a common ATN/AMHS standard or for a common specification.

If LDAP protocol exchanges are performed across boundaries, or irrespective of national boundaries, within e.g. an ICAO Region (typically an ICAO region with a (non-ATN) IP infrastructure), then some profiling may be required, with a status to be determined.

In such a scenario, replication and/or synchronization between ATN/AMHS Directory Servers would still be performed using X.500 protocols.

3.3Scenario 2: “LDAP version” of the ATN/AMHS directory

In this scenario, the LDAP Directory server must support ATN/AMHS directory information, and more specifically at least the simplified DIT structure in support of AMHS address conversion (see ICAO Document 9739 [3]).

To support the same information model, the LDAP AMHS Directory must support the same OCs and ATs as the X.500-base ATN directory, i.e. the aforementioned OCs and ATs from X.500, X.402 and the ATN/AMHS specifics of Sub-Volume 7.

Whilst the X.500 standard OCs and ATs are generally[1] supported by LDAPv3 implementations, based on the specification of RFC2256 (see [10]), it may not be the case for X.402 attributes. Furthermore ATN-defined attributes would require extensions to the directory database, making use of the schema extension mechanisms included in the LDAPv3 standards and implementations.

The ATN Directory schema as defined in Sub-Volume 7 also includes other elements:

  • attribute syntaxes for ATN-specific attribute types; they are part of the ASN.1 description of these attribute types;
  • name forms;
  • structure rules;
  • requirements on the support of matching rules, based on the matching rule definitions of X.402, X.413 (for MHS-related matching rules) and of X.501.

There are two major limitations to the support of these elements in an LDAP directory:

  • complex attribute syntaxes defined in ASN.1 for X.402- or atn-specific attribute types cannot be defined with the BNF syntaxes of LDAP. For example, BNF does not include an equivalent for the SEQUENCE and SET syntax elements which exist in ASN.1. In the case of existing complex attribute types such as “userCertificate”, the LDAP syntax is simply “binary” and the certificate is supposed to be encoded/decoded out of the LDAP environment. Another example of such existing attribute types is the X.402 “MHS DL Policy” which is not supported in LDAP;
  • when LDAP BNF syntaxes for complex elements exist, e.g. for MHS OR Address, matching rules enabling to use these syntaxes are not necessarily defined or supported.

The ATN specific attribute types in support of AMHS have been deliberately specified with simple syntaxes. Therefore they could easily be re-specified in BNF for inclusion in an LDAP directory, as part of extended schema definitions.

However, this is not true for X.402 attribute types, which in some cases are more complex. The issue of matching rules is even more problematic. Technical feasibility would first have to be determined, taking into consideration the limitations of the BNF syntax. Then, to be correctly supported by LDAP, they would require a formal specification, including OID registration by a competent body. This should probably be the subject of a new RFC (either “stand-alone” or an addition to an existing one). Finally, since support of new matching rules requires additional software development by LDAP system implementers, all of this only makes sense if it is ascertained that the specified additions will be implemented by LDAP product suppliers.

Considering that one of the main goals of using LDAP in the AMHS environment is to facilitate the directory implementation through the use of COTS products, there is an intrinsic contradiction between the constraints defined above and the initial objective.

It is consequently suggested not to pursue with this scenario of specifying an “LDAP version” of the ATN/AMHS Directory.

However, the flexibility and ease of implementation of an LDAP directory should not be totally rejected for AMHS. Therefore, another scenario is proposed hereafter making use of the same principles, i.e. re-define a LDAP directory schema, but with a more limited scope than the entire ATN/AMHS directory.

3.4Scenario 2a: LDAP Directory in support of AMHS address conversion

3.4.1Description and assessment

One of the first goals of Directory in support of AMHS is to facilitate the AFTN to AMHS address conversion, and vice-versa. An address conversion strategy meeting this goal has been included in the Draft 2nd Edition of Document 9739 (Part 3, Chapter 6, sections 6.2.1.5.10 to 6.2.1.5.20). It is based upon the ATN Directory SARPs, i.e. it uses a subset of the ATN Directory (X.500) Schema and DIT, and X.500 operations.

Furthermore, it is a common understanding in the ATSO community that only CAAS and XF addressing schemes will be implemented in the short term. This assumption would further simplify the address conversion strategy mentioned above.

The proposed scenario 2a consists in developing the short specification for an LDAP Directory meeting implementing the proposed address conversion strategy, but through the use of a stand-alone LDAP database and of LDAP operations. This scenario and the associated specification should be seen as “short-term implementation guidance”, but they could have a significant impact in facilitating the AFTN to AMHS transition. Therefore, an appropriate status should be determined for this material if this scenario is adopted by the ACP.

3.4.2Initial study

A prototype specification and implementation of the above scenario has been developed, for the conversion of AFTN addresses into AMHS addresses complying with a CAAS addressing scheme.

The prototype is based upon a directory schema made of:

  • a Directory Information Tree (DIT) identical to the DIT included in Doc 9739, and repeated in Appendix A to this paper, in support of AFTN/AMHS address conversion;
  • a general or core schema conformant to RFC2252 and RFC2256, i.e. implementing the object-classes, attribute-types, syntaxes and matching-rules defined in these documents. Obviously not all of them are required, but LDAP Directory software generally implements such a general schema, so there is not need to reduce the specification;
  • a definition of specific attribute-types and object-classes, derived from the ATN-specific ATs and OCs defined in Sub-Volume 7. These new LDAP ATs and OCs are specified with a BNF form:
  • attribute types:
  • atn-ICAO-designator,
  • atn-Amhs-addressing-scheme,
  • atn-AmhsMD-namingcontext,
  • atn-facilityName,
  • atn-version,
  • admd,
  • prmd;
  • object classes:
  • atn-AmhsMD,
  • atn-Organization,
  • atn-OrganizationalUnit.
  • standard (i.e. defined in RFC2252) matching rules and syntaxes are used for the specification and query of these specific ATs and OCs.

The corresponding BNF syntax is provided in Appendix A.

The address conversion algorithm described in Doc 9739 sections 6.2.1.5.17 and 6.2.1.5.18 for a X.500 context is adapted to the LDAP context and presented in Appendix A. LDAP query examples participating to this algorithm are also provided.

3.5Summary of scenario presentation

Scenario 1 (LDAP access to the ATN/AMHS directory) is primarily considered as a local matter. Some work may be needed to harmonize its use so as to facilitate cross-border queries. This is for further study.

Scenario 2 (LDAP version of ATN/AMHS Directory) is not recommended for further study considering the difficulties which are foreseen.

In summary, it is recommended that the Scenario 2a above consisting in the specification of an “LDAP Directory in support of AMHS address conversion” be further studied by the ACP WGN for potential implementation by the ATSOs which are intending to deploy AMHS.

4Future work

The following tasks and milestones need to performed by ACP WGN and SGN3 for the continuation of this work about LDAP:

  • approval of the recommendation to further develop the specification of an “LDAP Directory in support of AMHS address conversion” as described in scenario 2a above,
  • determination of the future status of the material to be developed, and of the document in which it would be included,
  • determine potential short-term extensions to this work to support other styles of directory usage,
  • further study to complement, if needed, and validate the initial specification provide in the present working paper,
  • analyze the implementation of the scenario in a Regional (or Global if deemed appropriate) distributed environment, including replication and synchronization issues,
  • analyze interoperability or inter-working with the ATN Directory as specified in Document 9705,
  • document these aspects to enable scenario implementation.

5Recommendations to the meeting

The meeting is invited to confirm the potential benefit of LDAP-based Directory architectures for ground communications between ATSOs.

The working group is invited to endorse the recommendation to further develop the specification of an “LDAP Directory in support of AMHS address conversion”, as presented in Scenario 2a above, for potential implementation by the ATSOs which are intending to deploy AMHS

6APPENDIX A: PROTOTYPE SPECIFICATION OF SCENARIO 2A

6.1DIT structure

The following DIT structure (extracted from Doc 9739, draft Edition 2 to be published) is implemented in the prototype of Scenario 2a:


6.2Additional schema elements

The following schema elements are defined as defined as part of the prototype implementation:

# Prototype schema for AMHS address conversion

# (CAAS AMHS addresses  AFTN addresses)

#######################

# ATN attribute-types #

#######################