VIEWS: 8 PAGES: 10 POSTED ON: 9/2/2012
ACP-WGM19/WP-06 International Civil Aviation Organization 5/30/2012 WORKING PAPER AERONAUTICAL COMMUNICATIONS PANEL (ACP) WORKING GROUP M MEETING 19 Bucharest, Romania 30 May – 1 June 2012 Agenda Item 3a: ATN Security Standards Proposal to Update Doc 9880 With Secure Dialogue Service Prepared by: FAA Coordinated with: EUROCONTROL SUMMARY 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. ACTION The Secretary may use this version for action items assigned at Meeting 17. 1. INTRODUCTION ACP-WGW19/WP-06 -2- 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 protocol stack. Section 2.4 describes how the Secure Dialogue Service facilitates the optional implementation and use of security. 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. DISCUSSION 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 SESAR. Figure 1 depicts the ATN/OSI protocol stack next to the ATN/IPS protocol stack. -3- ACP-WGW19/WP-06 ATN/OSI ATN/IPS 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 Protocol Protocol Stack OSI Network (CLNP) Stack IP (Doc 9880) (Doc 9896) Mobile Sub-Network Dependent Mobile IP Convergence Function (M-SNDCF) Future Comm VDL/2 Air/Ground Link 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 Rules (PER). 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. ACP-WGW19/WP-06 -4- ICAO Doc 9705 ATN/OSI CPDLC/CM ULCS App ASE S-ASO ULCS SESE TP4 SSO ACSE CLNP ULCS with M-SNDCF Security VDL/2 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 cryptographic primitives. 2.3 Proposal for Simplification of Security in the ATN/OSI Protocol Stack – Secure Dialogue Service 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. -5- ACP-WGW19/WP-06 ICAO Doc 9880 ATN/OSI with Secure Dialogue Service CPDLC/CM Secure Dialogue Service ULCS TP4 CLNP M-SNDCF VDL/2 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 operational domain: If security is not used in a particular domain the Secure Dialogue Service may not be implemented, The Secure Dialogue service could be implemented but its use or not would depend on the operational domain 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. ACP-WGW19/WP-06 -6- CPDLC/CM CPDLC/CM CPDLC/CM Secure Dialogue Secure Dialogue Service Service 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. -7- ACP-WGW19/WP-06 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. Application User ATN-App AE CF ATN-App ASE Dialogue Service Boundary Security ASO SSO ACSE SESE Presentation Service Provider Figure 5 – ULCS with Security Application User ATN-App AE CF ATN-App ASE Secure Dialogue Service Boundary SSO Secure Dialogue Svc Standard ULCS Dialogue Service Boundary ACSE 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 Function. 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- ACP-WGW19/WP-06 -8- 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 -9- ACP-WGW19/WP-06 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 - 2.10 Summary 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 ATN/IPS. 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.
Pages to are hidden for
"TITLE - ICAO"Please download to view full document