International Civil Aviation Organization 5/30/2012
AERONAUTICAL COMMUNICATIONS PANEL (ACP)
WORKING GROUP M
Bucharest, Romania 30 May – 1 June 2012
Agenda Item 3a: ATN Security Standards
Proposal to Update Doc 9880
Secure Dialogue Service
Prepared by: FAA
Coordinated with: EUROCONTROL
This Working Paper proposes to update Doc 9880 with the Secure Dialogue
Service. The Secure Dialogue Service is an alternative to implementing
security in the ULCS. Besides reducing ULCS complexity the Secure
Dialogue Service permits security to be done all in one sub-layer rather than
involving CM for key exchange. The Secure Dialogue Service facilitates the
optional implementation of security and it can be used in the ATN/IPS to
support legacy applications.
The Secretary may use this version for action items assigned at Meeting 17.
1.1 This Working Paper proposes to update Doc 9880 with the Secure Dialogue Service. The
Secure Dialogue Service is an alternative to implementing security in the ULCS. Besides reducing ULCS
complexity it can be used in the ATN/IPS to support legacy applications. It also facilitates the optional
implementation of security.
1.2 This working paper is organized as follows:
Section 2.1 contains background information on the ATN/OSI and ATN/IPS protocol stacks.
Section 2.2 describes the original addition of security to the ATN/OSI stack in Doc 9705 Edition 3.
Section 2.3 describes the proposal for the Secure Dialogue Service as a simplification of the ATN/OSI
Section 2.4 describes how the Secure Dialogue Service facilitates the optional implementation and use of
Section 2.5 describes the security requirements in the ATN/IPS protocol stack.
Section 2.6 describes the documentation changes to Doc 9880 Part III, Chapter 2, ULCS.
Section 2.7 describes the documentation changes to Doc 9880 Part IV B, Security
Section 2.8 describes the documentation changes to Doc 9880 Part I, Context Management
Section 2.9 describes compatibility with existing implementations of Doc 9705 Ed2
Section 2.10 summarizes the Secure Dialogue Service proposal
Section 3 describes action by the meeting.
2.1 Background (ATN/OSI and ATN/IPS)
The Aeronautical Telecommunication Network (ATN) was originally envisioned to be based on Open
System Interconnect (OSI) standards. The ATN/OSI standards define a complete bit-oriented protocol
stack meant to support ATM application payloads. The ATN/OSI protocol stack was originally defined
in ICAO Doc 9705. Doc 9705 is being replaced by ICAO Doc 9880.
In 2008, ICAO defined a version of the ATN which is based on Internet Engineering Task Force (IETF)
Internet Protocol Suite (IPS) standards. The ATN/IPS is capable of supporting legacy ATN applications
defined in ICAO DOC 9880 and it is designed to support emerging ATM applications from NextGen and
Figure 1 depicts the ATN/OSI protocol stack next to the ATN/IPS protocol stack.
Application ATN PER Encoded Messages Application ATN PER Encoded Messages
(ICAO Air-Ground App standards - (ICAO Air-Ground App standards -
(e.g., CPDLC,CM) Doc 9880) (e.g., CPDLC,CM) Doc 9880)
ATN Upper Layer Communicatios
Service (ULCS) IP Dialogue Service
ATN/OSI OSI Transport (TP4) ATN/IPS TCP
Stack OSI Network (CLNP) Stack IP
(Doc 9880) (Doc 9896)
Mobile Sub-Network Dependent Mobile IP
Convergence Function (M-SNDCF)
Figure 1 – ATN/OSI and ATN/IPS Protocol Stack
The application layer includes the technical part of the application, such as the Controller Pilot Data Link
(CPDLC) and Context Management (CM) application, available in both stacks. CPDLC as the name
implies is for air/to ground data communication exchanges between a Controller and Pilot rather than
voice. CM is a support application to initiate communications over the air-ground data link. In both stacks
the application messages are defined using ASN.1 syntax and are encoded following the Packed Encoding
The ATN/OSI stack consists of several elements. The Upper Layer Communications Service (ULCS)
presents a common logical interface to the applications called the Dialogue Service. The ULCS’s primary
function is to establish a session among communicating peers on the airborne and ground sides. The
ULCS contains a streamlined version of the OSI Presentation and Session Layers. The ULCS runs over
the OSI defined class 4 transport protocol (TP4). TP4 in turn runs over the OSI network layer using the
CLNP protocol. In the air-ground environment CLNP operates over the Mobile Sub-Network Dependent
Convergence Function (M-SNDCF). The M-SNDCF runs over VHF Data Link Mode 2 (VDL/2).
The ATN/IPS stack uses the well-known Mobile IP over TCP/IP or UDP/IP as the mobility solution.
This stack is intended to run over future air/ground sub-networks which have higher bandwidth than
VLD/2. Doc 9896 includes an IP Dialogue Service which allows legacy (ATN/OSI) applications (i.e.,
CPDLC and CM) to operate in the ATN/IPS environment. The IP Dialogue Service presents the same
logical interface to legacy applications as in the OSI environment.
2.2 Original Security Addition to the OSI Protocol Stack
The standards for securing air-ground communications were developed in ICAO communications panels
as an extension to the OSI standards. Figure 2 depicts the addition to the ATN/OSI protocol stack as
specified in Doc 9705 Edition 3.
ICAO Doc 9705 ATN/OSI
TP4 SSO ACSE
Figure 2 – Original (Doc 9705) Protocol Stack with Security
Edition 3 of Doc 9705 placed a new service object, the Security Application Service Object (S-ASO), in
the ULCS. The S-ASO uses the OSI-defined Security Exchange Service Element (SESE) for transfer of
security information and invokes the ATN-defined Security Service Object (SSO), which implements the
2.3 Proposal for Simplification of Security in the ATN/OSI Protocol Stack – Secure
The Edition 3 placement of security in the ULCS adds complexity to the ULCS when compared with
Edition 2 without security. Implementation of Edition 3 would require a completely new implementation
of the current ULCS. In order to simplify implementation of ATN Security, EUROCONTROL and the
FAA have been coordinating to define an alternative implementation that would be simpler to implement
and not require significant changes to the Doc 9880 ULCS. This alternative implementation is called the
Secure Dialogue Service. Figure 3 depicts the insertion of the Secure Dialogue Service as a sub-layer
between the applications and the ULCS. Note that the Secure Dialogue Service still implements the SSO
to perform the cryptographic functions. However it eliminates the complexity of doing security in the
ULCS using the S-ASO and SESE.
ICAO Doc 9880 ATN/OSI
Secure Dialogue Service
Figure 3 – Proposed (Doc 9880) ATN/OSI Protocol Stack with Secure Dialogue Service
2.4 Optional Implementation/Use of Security with the Secure Dialogue Service
The Secure Dialogue Service approach provides flexibility in terms of implementation and optional use or
non-use as is depicted in Figure 4
The proposal for the Secure Dialogue Service permits implementation options depending on the
If security is not used in a particular domain the Secure Dialogue Service may not be
The Secure Dialogue service could be implemented but its use or not would depend on the
It is important to note that Doc 9880 Applications and the ULCS would be implemented the same
whether or not the Secure Dialogue Service is implemented. The Dialogue Service Interface and secure
Dialogue Service Interface are the same. Use or non-use is a local matter which is signalled in the
applications. This capability is already in the Doc 9880 applications.
CPDLC/CM CPDLC/CM CPDLC/CM
Secure Dialogue Secure Dialogue
ULCS ULCS ULCS
TP4 TP4 TP4
CLNP CLNP CLNP
M-SNDCF M-SNDCF M-SNDCF
VDL/2 VDL/2 VDL/2
Figure 4 – Optional Implementation/Use of the Secure Dialogue Service
2.5 Security Requirements in ATN/IPS Protocol Stack
ICAO has defined a new version of the ATN which uses the Internet Protocol Suite (IPS). This stack has
been defined in ICAO Doc 9896. It uses the well-known Mobile IP as the mobility solution over TCP/IP
or UDP/IP protocol. Doc 9896 includes an IP Dialogue Service which allows legacy (ATN/OSI)
applications such as CPDLC and CM to operate in the ATN/IPS environment. The IP Dialogue Service
presents the same logical interface to legacy applications as in the OSI environment.
All security requirements in ATN/IPS are defined by section 2.5 SECURITY REQUIREMENTS of
ICAO DOC 9896 Ed 1 - Part I — Detailed Technical Specifications Chapter 2 — Requirements
The ICAO DOC 9896 Air-ground application layer security requirements are the following:
2.5.23 IPS mobile nodes and correspondent nodes may implement application layer security at
the IPS dialogue service boundary, which is specified in Part II, 1.4, of this document.
2.5.24 IPS mobile nodes and correspondent nodes shall append a keyed hashed message
authentication code (HMAC) as specified in RFC 2104 using SHA-256 as the cryptographic hash
function, when application layer security is used.
2.5.25 An HMAC tag truncated to 32 bits shall be computed over the user data concatenated with
a 32-bit send sequence number for replay protection, when application layer security is used.
2.5.26 IKEv2 shall be used for key establishment as specified in 2.5.12 to 2.5.20, when
application layer security is used.
2.6 Changes to Doc 9880 Part III, Chapter 2, Upper Layer Communications Service
Figures 5 and 6 depict the ULCS with and without security in the ULCS.
Dialogue Service Boundary
Presentation Service Provider
Figure 5 – ULCS with Security
Secure Dialogue Service Boundary
SSO Secure Dialogue Svc
Standard ULCS Dialogue Service Boundary
Presentation Service Provider
Figure 6 – ULCS with Security moved to the Secure Dialogue Service
As depicted in Figure 5, implementing security in the ULCS requires insertion of the Security ASO and
SESE. It also involves modification of ACSE. The net result is a significant modification of the Control
The "outer" dialogue service CF controls the interactions between the Application ASE (e.g.
CPDLC air or ground ASE), the Security ASO, ACSE and the supporting transport service.
The Security ASO itself contains an "inner" CF, which controls the interactions between the S-
ASO upper and lower service boundaries, the embedded SESE upper and lower service
boundaries, and the SSO.
As depicted in Figure 6 implementing security with the Secure Dialogue Service removes the S-ASO,
SESE, the enhanced ACSE, and the extended logic of the ULCS Control Function. The same SSO
primitives are invoked directly by Secure Dialogue Service primitives.
Note that although it is depicted in Figure 6, the Secure Dialogue Service will be specified in Doc 9880
Part IVB (not in Part III, Chapter 2) as described in Section 7 below. In this way the Secure Dialogue
Service can be referenced from Doc 9896 where it operates over the IP Dialogue Service.
Table 1 summarizes the ULCS changes.
Table 1 – Changes to Doc 9880 Part III, Chapter 2
Modify the overall architecture to remove the Security ASO and SESE.
Change the Control Function essentially back to the equivalent of Doc 9705 Edition 2.
Remove the enhanced ACSE features.
Remove the Security ASO
Remove the SESE
Modify the ASN.1 structures to remove the security exchange items imported from the
OSI security framework.
Note that PDR changes not related to security will remain in Doc 9880, Chapter 2.
2.7 Changes to Doc 9880, Part IV B, Security
The primary change to Doc 9880 Part IV B is to insert a new section that specifies the Secure Dialogue
Service Primitives (see Table 2). In addition, new ASN.1 structures must be introduced to carry the
information that had been carried in the ULCS security exchange items
Table 2 – Secure Dialogue Service Primitives
sD-START Request primitive
sD-START Indication primitive
sD-START Response primitive
sD-START Confirmation primitive
sD-DATA Request primitive
sD-DATA Indication primitive
sD-END Request primitive
sD-END Indication primitive
sD-END Response primitive
sD-END Confirmation primitive
sD-ABORT Request primitive
sD-ABORT Indication primitive
sD-P-ABORT Indication primitive
2.8 Changes to Doc 9880 Part I, Context Management
In current Doc 9880 Part I, Context Management, public keys for ground applications are returned in the
CM Logon Response message. This approach distributes security across multiple layers (i.e. CM and the
Secure Dialogue Service). All other security parameters are retrieved from information exchanged within
the Secure Dialogue Service.
With the Secure Dialogue Service it would be possible to have the application public keys sent along with
other security information within the Secure Dialogue Service.
This would require specifying this in the Secure Dialogue Service and removing it from the Doc 9880
CM. The changes are mainly to remove the public key structures from the ASN.1 message definitions in
CM and add them to the SDS.
2.9 Compatibility with Existing Implementations of Doc 9705 Ed2
In Europe, the single European Sky Regulation (EC) 29/2009, foresees the provision of data link services in
Europe, with operations starting from February 2013.
The baseline standard adopted in support of this regulation is the second edition (1999) of Doc 9705,
updated by a number of Proposed Defect Report (PDR) resolutions approved by the ATN Panel .
The ATN/OSI upper layers specified in Doc 9705 Ed 2 Sub-Volume IV, are technically identical to the draft
Doc 9880 Part III Chapter 2, ì.e. the Basic Dialogue Service subset. The CPDLC and CM applications specified
in Doc 9705 Ed 2 Sub-Volume II., is identical to Doc 9880 Part I Chapter 3.
Any changes proposed for the Secure Dialogue Service, in the upper layers and CM, will need to maintain
compatibility with the Doc 9705 Ed2 documents. After removal of the security functionality from Doc 9880,
the remaining functionality corresponds to the basic dialogue service subset, which should be technically
similar to the Ed9705 Ed2 upper layers. To ensure compatibility with Ed2 9705 a screening of all PDRs
incorporated in the revised 9880 upper layers needs to be conducted based on identified criteria for
incorporation of the PDRs. For example, only non-security related PDRs would be incorporated. Amendment
proposals presented in previous Working Group M meetings not related to the Secure Dialogue Service would
also be incorporated in Doc 9880 Part IV B also.
ACP-WGW19/WP-06 - 10 -
The original Doc 9705 Edition 3 approach to ATN Security is a validated standard. It has the
disadvantage that its implementation in the ULCS introduces significant complexity to the ULCS and
requires that the complete ULCS be replaced.
The proposed Secure Dialogue Service approach would simplify the implementation of ATN Security.
o Security is all performed in the same place, i.e., in the Secure Dialogue Service sub-layer.
o The Doc 9880 ULCS can be updated to remove the security features. This will become
an equivalent to Doc 9705 Edition 2 but with PDRs incorporated.
o The Secure Dialogue Service provides implementation options: It can be implemented or
not implemented and if implemented used or not depending on the operational domain.
o In any case the applications and ULCS would be the same
The Secure Dialogue Service has the added advantage that it is consistent with the security provisions in
3. ACTION BY THE MEETING
3.1 The Working Group is invited to consider the Secure Dialogue Service as an alternative
to ULCS security.
3.2 The meeting should note that the FAA would be able to complete the ICAO DOC 9880
required changes and the proposal for the SDS by Dec 2012 and to complete validation by June 2013.