European Organisation for the Safety of Air Navigation AMHS Community Specification SpeakerBolek Gasztych OrganisationEUROCONTROL Date and venueDecember

European Organisation for the Safety of Air Navigation

AMHS Community Specification Speaker Bolek Gasztych

Organisation EUROCONTROL

Date and venue December 2008, Chennai

2

AMHS Community Specification Introduction

Present the concept of the AMHS Community Specification development

Describe the development process

Present the current status of development

Present the next steps


AMHS Community Specification

Why develop a Community Specification?

4

AMHS Community Specification European Commission Request

EUROCONTROL is requested to assist the European Commission in the development of Community Specifications

EUROCONTROL is requested to develop Specifications for the AMHS within the European Air Traffic Management Network (EATMN)

Request for the Development of AMHS Specifications; European Commission; 30/03/2007

5

AMHS Specification Essential Requirements

• Drawn up by the ESOs (CEN/CENELEC/ETSI) in cooperation with Eurocae on technical issues

• Drawn up by EUROCONTROL on matters of operational coordination

Recognized as Means of Compliance with the ER and/or IR

SES interoperability Regulation (552/2004)

Drafts developed by EUROCONTROL as EC Regulations

Community Specifications

(Voluntary Standards)

Essential Requirement

s

Implementing Rules

6


Community Specifications

(Voluntary Standards)

Essential Requirement

s

Implementing Rules

Seamless operation

Safety

Civil-military coordination

Support of new concepts of operation

Environmental constraints

Principles governing the logical architecture

Principles governing the construction of systems

Regulation (EC) No 552/2004; Annex II; Parts A&B

7


Seamless Operation: Communication systems shall be designed, built,

maintained and operated using the appropriate and validated procedures, in such a way as to achieve the required performances within a given volume of airspace or for a specific application, in particular in terms of communication processing time, integrity, availability and continuity of function.

The communications network within the EATMN shall be such as to meet the requirements of quality of service, coverage and redundancy.

Regulation (EC) No 552/2004; Annex II, S4 Communications systems

8


Support for new concepts of operation: Communication systems shall support the implementation

of advanced, agreed and validated concepts of operation for all phases of flight.

Regulation (EC) No 552/2004; Annex II, S4 Communications systems

9


Safety: Systems and operations of the EATMN shall achieve agreed high levels of safety.

Agreed safety management and reporting methodologies shall be established to achieve this.

In respect of appropriate ground-based systems, or parts thereof, these high levels of safety shall be enhanced by safety nets which shall be subject to agreed common performance characteristics.

A harmonised set of safety requirements for the design, implementation, maintenance and operation of systems and their constituents, both for normal and degraded modes of operation, shall be defined with a view to achieving the agreed safety levels, for all phases of flight and for the entire EATMN.

Systems shall be designed, built, maintained and operated, using the appropriate and validated procedures, in such a way that the tasks assigned to the control staff are compatible with human capabilities, in both the normal and degraded modes of operation, and are consistent with required safety levels.

Systems shall be designed, built, maintained and operated using the appropriate and validated procedures, in such a way as to be free from harmful interference in their normal operational environment.

Regulation (EC) No 552/2004; Annex II, Part A: General Requirements

10


Civil-military co-ordination: The EATMN, its systems and their constituents shall

support the progressive implementation of civil/military coordination, to the extent necessary for effective airspace and air traffic flow management, and the safe and efficient use of airspace by all users, through the application of the concept of the flexible use of airspace.

To achieve these objectives, the EATMN, its systems and their constituents shall support the timely sharing of correct and consistent information covering all phases of flight, between civil and military parties.

Account should be taken of national security requirements.


11


Environmental constraints: Systems and operations of the EATMN shall take into

account the need to minimise environmental impact in accordance with Community legislation.


12


Principles governing the logical architecture of systems: Systems shall be designed and progressively integrated

with the objective of achieving a coherent and increasingly harmonised, evolutionary and validated logical architecture within the EATMN.


13


Principles governing the construction of systems: Systems shall be designed, built and maintained on the

grounds of sound engineering principles, in particular those relating to modularity, enabling interchangeability of constituents, high availability, and redundancy and fault tolerance of critical constituents.


14

AMHS Community Specification AMHS Positioning - Concept

Today’s infrastructure Future

infrastructure

SES Regulations

evolution

“Communication systems shall be designed, built, maintained and operated using the appropriate and validated procedures, in such a way as to achieve the required performances ... for a specific application, in particular in terms of communication processing time, integrity, availability and continuity of function”

AMHS CS

Presumption of

compliance

Supporting new concepts of operation Enabling OIs (SESAR / SWIM)



The Development Process

16

AMHS Specification CS Development Process

European Commission Request

Initial Plan

Specification Approach

Stakeholder soundings

Stakeholder workshop to present options

CS Development

Formal consultation

Summary of Responses

CS update

Eurocontrol support

Initial Plan

Final Specification

Step 1

Step 2

Step 3

17

AMHS Community Specification Review Stage

Stakeholder discussion

Options WorkshopStep 1

Questionnaire

Option 2

Initial Plan

Initial Plan


Drafting

CS Development

Step 2Review

Draft AMHS SpecReview

Document review complete

Updates and further reviews

Contributions to the Review Group from ANSPs and industry



AMHS CS Proposed Technical Content

19

AMHS Community Specification AMHS Positioning - Messaging

X.400 MHS Base Standards

MHS ISPs

Basic ATSMHS

EUR Profile

Extended ATSMHS

AFTN headerRecordingBinary content

Extended message sizeUse of TCP/IP

SecurityUse of Directory

20

AMHS Community Specification Document Structure

Specification is organised as a number of chapters and annexes

Chapters in main body provide contextual guidance and point to the self contained annexes with normative requirements

Chapter 1 contains introductory material describing the purpose and scope of the specification

Chapter 2 describes the basic level of interoperability for AMHS

Chapter 3 describes the introduction to Directory systems and procedures

Chapter 4 describes the Security issues

Chapter 5 describes a suggested Security mechanism and procedures to support the Extended ATSMHS

21


Chapter 6 describes additional requirements relating to implementation options, testing, and validation

Chapter 7 describes some of the transition and coexistence issues

Chapter 8 addresses traceability between the means of compliance in the AMHS CS and Single European Sky essential requirements

Chapter 9 describes the procedures for maintaining and updating the AMHS CS

Chapter 10 contains a list of documents

22


Annex A (normative) contains detailed requirements for the Air Traffic Services (ATS) Message Handling functionality at the level

of the Basic ATSMHS. Annex B (normative) contains detailed requirements for the ATS

Message Handling functionality at the Extended ATSMHS level of service, requiring support of Functional Groups (FG) for the Basic ATSMHS (Basic FG), use of file transfer body parts for binary data exchange (FTBP FG), use of interpersonal messaging heading extensions (IHE FG) and use of Directory (DIR FG)

Support of AMHS Security (SEC FG) is foreseen in the future Annex C (normative) contains detailed requirements for Directory

systems to support the DIR FG of the Extended ATSMHS

Annex D (informative) indicates high level requirements for security mechanisms to support the SEC FG of the Extended

ATSMHS

23

AMHS Community Specification Basic level of interoperability for AMHS

The detailed technical provision for the AMHS are specified in ICAO doc 9880

ICAO Annex 10 is being updated to include ATN operation over the Internet Protocol Suite (ATN/IPS)

Both Doc 9880 and the ICAO EUR AMHS Manual (Doc 020) specify AMHS end systems making use of TCP/IP lower layers through an RFC1006 interface for IPv4 or RFC 2126 for IPv6

During transition phase, interoperability with legacy AFTN/CIDIN is achieved by the use of AFTN/AMHS gateways as specified in Doc 9880

Interoperability with Military AFTN usage can be achieved by using AFTN/AMHS Gateways or use of civil UAs. (Future MMHS/AMHS gateway could be envisaged – out of scope of this AMHS CS)

24

AMHS Community Specification Extended AMHS functionality

Use of File Transfer Body Parts (FTBP). This functional group

enables the transfer of binary data between direct AMHS users Use of IPM Heading Extensions (IHE). This functional group uses

standard message fields instead of the AMHS-specific ATS

Message Header which is required in the Basic ATSMHS AMHS Security (SEC). This functional group enables support of

the AMHS security policy, providing message origin authentication and content integrity assurance between direct AMHS users

Use of Directory (DIR). This functional group enables support of the ATN Directory through the use of a DUA included in the AMHS End System



Directory

26

AMHS Community Specification General Directory Architecture

fromDSA1

DIB

fromDSA2

DUA

DUA

DUA

DUA

DUA

DUA

DAP DSP,DISP DAP

Chaining / Shadowing

private data

Country 1 Country 2

DSA1 DSA2

27

AMHS Community Specification Directory - General Requirements (1)

Support of the AMHS Directory (DIR) functional group is required for full conformance to the Extended AMHS

DIR – Directory services allow user to obtain directory information about user application and services

DIR is composed of Directory Information Base (DIB) Directory System Agent (DSA) and Directory User Agent (DUA)

DIB is organised into a tree shaped hierarchy – Directory information Tree (DIT)

Each DSA shall:

Have a common schema for data being replicated

Support a common directory replication protocol

Each DSA shall implement Directory System Protocol (DSP) to allow chaining operation

Each DSA shall implement Directory Information Shadowing Protocol (DISP) to support data shadowing

28

AMHS Community Specification Directory - General Requirements (2)

Each DSA shall support the bind operation using a minimum simple authentication for DAP, DSP and DISP as defined in the base standards

Each DSA shall allow additional directory object classes to be included to allow the use of this service by other applications

Each DSA shall implement Directory Access Protocol (DAP)

The DSA may implement other access protocol based on LDAP v3 or a proprietary protocol as a local issue without impact on interoperability

29

AMHS Community Specification Directory - Specific Requirements

Each Directory implementation shall support: Name resolution

Distribution list (DL) expansion and management

Determination of user capabilities

AFTN/AMHS address conversion and publication

Retrieval of security certificates and CRLs

The Directory information tree exported by Border DSAs shall conform to the DIT structure defined in ICAO technical provisions for ATN Directory Services

Each directory implementation should support:

AMHS systems management information

Address book

Support for system configuration (MTA, Gateway)

30

AMHS Community Specification Initial Directory Architecture

Country border

DSA

Ext. Border

DSA

DSA

Country border

DSA

DSA

Europe

AMC

DSA

Country border

DSADSA

Europe Directory Management Domain

External Directory Management Domains

ANSP DMD

ANSPDMD

ManualSync.

AIRACCycle

AIRACCycle

AIRACCycle

ANSP DMD

AIRACCycle

31

AMHS Community Specification Final Directory Architecture

Country border

DSA

Ext. Border

DSA

DSA

Country border

DSA

DSA

Europe

DSA

DSA

Country border

DSADSA

Europe Directory Management Domain

External Directory Management Domains

ANSP DMD

ANSPDMD

Sync. process

DISP DISP

DISP or DSP

DISP

DISP

ANSP DMD



Security

33

AMHS Community Specification Security

It is recognised that the provision of AMHS Security services is not as advanced as other elements of the Extended ATSMHS

The security requirements in Annex D are to be considered as

advisory indications of the evolutionary direction

34

AMHS Community Specification End-to-End Message Security

Message Origin Authentication Check

Originator’s certificate (optional)

X.400 envelope

Public key, signed by trusted CA

Message hash, encrypted with private key

Message content to be

protected

S0 Security Class

• Content integrity

• Origin Authentication

• Proof of delivery

Extended ATS MHS

Passed transparently through Message Transfer Service

35

AMHS Community Specification End-to-End Message Security

State A CA

State B CA

State C CA

Name

Public key

Signed by CA

Issues certificates

Certification Authorities

Message signed by an originator in State A with that user’s private key can be verified by recipient in State C using the originator’s public key

PKI enables recipient to trust that the public key is authentic

Public Key Infrastructure (PKI) Secure security key distribution

Trust between security domains (States)

36

AMHS Community Specification Global AMHS Architecture including CA

37

AMHS Community Specification Security - General Requirements

Support of the AMHS Security (SEC) functional group is required for full conformance to the Extended AMHS

An AMHS implementation shall include protocol provisions as necessary to comply with the local security policy relating to aeronautical data access and interchange.

Implementations shall be conformant with the Extended AMHS and in particular the security aspects of ATN relevant for ground-ground communication

The Extended AMHS explicitly provides the following security services between ATS Message User Agents:

Content integrity

Message sequence integrity

Message origin authentication

Proof of delivery (when IPNs are used)

38

AMHS Community Specification Security - Specific Requirements (1)

Each State participating in the AMHS security scheme shall designate a Trusted Third Party (TTP) acting as a Root Certificate Authority (CA) which issues certificates and certificate revocation lists (CRLs)

The TTP shall be conformant with the ETSI Guide EG 201 057, which defines the role and attribution of a TTP acting as a CA in a PKI

Each CA shall develop a Certificate Policy, conformant to the certificate policy defined in ETSI specification TS 101 456 v1.4.3, that defines the creation, management and use of public key certificates that they issue

39


The Certificate Policy and Certificate Practice Statement shall be aligned with the framework presented in RFC 3647 “Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework”

The Certificate Policy and Certificate Practice Statements of a given State could be used by other States in establishing their trust relationships and operating policies such as cross certification

40


Each CA shall give simple access to the public certificate and CRL repository in its own domain

Each CA should distribute public key certificates and CRL using Directory Services

The cryptographic signing and hashing functions and parameter settings shall be conformant with ATN Security provisions (Elliptic Curve Cryptography – ECDSA)

The general certificate format used for ATN PKI certificates in Europe shall be conformant with the X.509 Format with parameters defined in chapter 8.4.3 of the ATN Security provisions

41

AMHS Community Specification European PKI – Initial Phase

European Community

CA ANSP i

CA ANSP j

CA ANSP k

CA ANSP x

CA ANSP l

42

AMHS Community Specification Final European Public Key Infrastructure

CA ANSP i

CA ANSP j

CA ANSP k

CA ANSP x

CA ANSP l

EU CA European

Community

CA ANSP x



The Next Steps for AMHS CS

44

Formal Consultation

Summary of Responses AMHS Specification

Step 3Formal Workshop

Final Report

AMHS Community Specification The Next Steps – Review Stage

Stakeholder discussion

Options WorkshopStep 1

Questionnaire

Option 2

Initial Plan

Initial Plan


Drafting

CS Development

Step 2Review

Draft AMHS Spec

45

Final ReportStep 3

AMHS Community Specification The Next Steps – Formal Consultation

Formal Consultation

Summary of Responses AMHS Specification

Formal Workshop

Consultation draft of AMHS Specification to be issued in January 2009

Formal Workshop after April 2009

EUROCONTROL AMHS Specification send to

European Commission by mid 2009



The End

Documents

European Organisation for the Safety of Air Navigation AMHS Community Specification SpeakerBolek Gasztych OrganisationEUROCONTROL Date and venueDecember