International Civil Aviation Organization CP-SDS WG 2/ WP03 26th June 2015 WORKING PAPER COMMUNICATIONS PANEL (CP) SECOND MEETING OF SECURE DIALOGUE SERVICE SUB WORKING GROUP (SDS SWG) Montreal, Canada 24 – 25 June 2015 Report of first CP SDS SWG meeting Presented by the SDS SWG Rapporteur Summary This document is the CP SDS SWG 1 Meeting Report. (6 pages) CP SDS SWG 2 WP03 ACP-WGW2 WP-013 -2- 1. The first sDS SWG meeting took place on Wednesday, April 29th to Thursday, April 30th 2015 at EUROCONTROL, Brussels, Belgium. 2. The meeting was attended by seven experts. The list of participants is in this report. 3. Two working papers were presented at the meeting. The first working paper was presented by Mr. Tom McParland addressing Draft of Requirements for the Secure Dialogue Service in Doc 9880, Part IV-B. The second working paper was presented my Mr. Mike Olive addressing Secure Dialogue Service Avionics Impact Analysis - preliminary status. 4. The meeting was opened by the sDS SWG meeting chairman, Mr. Vic Patel and discussed sDS standards development plan addressing the following: • • • • Phase 1 - Review sDS approach and investigate alternatives/enhancements ---- 6 months (started in early March 2015) • Evaluate initial solution of current sDS approach for DOC 9880 and DOC 9896 • Report on SDS development progress and actions taken during those reviews by the SDS SWG to the ACP WG M and WG I meetings • Products - Analysis report and ATN Security approach/Strategy document Phase 2 A - Update Upper layer Communications Service (ULCS) • Change to Edition 2 plus PDRs • Product - Update to Doc 9880 ULCS - Completed B – Update Context Management (CM) • Remove ASN.1 structures and logic to transmit Application Public Keys in CMResponse Message • Product – Update to Doc 9880 CM - Completed C – Update Security Provisions – 9 - 12 months • Change Cryptographic Suite and Certificate Profile • Incorporate Secure Dialogue Service • Products – Update to Doc 9880 Security Provisions Phase 3 - Doc 9880 and Doc 9896 Validation – 12 months • Develop validation plan • Perform validation • Prepare validation report • Products – Validation Plan, test scenarios, and validation report Phase 4 – Develop Guidance documents – 6 to 9 months • Products – Guidance document -3- ACP-WGW2 WP-013 5. During the sDS requirements discussion various topics were discussed in detail. Key items and decisions are as follows: i sDS version - The sDS will be included in version 3 of Doc 9880. ii On which DS primitives should have sDS primitives - It was decided that D-END should be protected since otherwise an attacker could end an active dialogue. iii On single key for Key Agreement and Digital Signatures Based on the previous Working Paper with the Amendment Proposal for this item it was decided that support for both would be signalled by Key Usage in the Certificate when a single certificate is uplinked. iv Section 7.1 of Draft Requirements Section needs to be updated to include IPS Dialogue Service. Table 7.1-1 should be deleted from the other part of the Security Sub-Volume and defined in this section. v Security Scenarios sDS scenarios need to be defined covering: • The air or ground entity supports/requires security and the peer entity does not. • Backwards compatibility vi Figure 7.1-1 of Draft Requirements Current figure shows sDS placement in the ULCS. This needs to be replaced by a figure showing the sDS over the ULCS and IPS dialogue service. Mr. Frederic Picard generated a draft figure (see attached file Figure7_1-1.png) After discussing the figure it was decided that the draft requirements primitives would assume this architecture rather than the current were the application called the dialogue service which in turn called the sDS. ACP-WGW2 WP-013 -4- vii Signature or MAC failure handling in the Draft requirements Discussion was what to do if the signature or MAC was not valid, e.g. 7.3.2.3 h). The group decided that a Provider Abort should be issued. Mr. Frederic Picard took an action item to see how this is handled in the ULCS implementation. viii Table 7.1-1 in Draft requirements It was decided that the Dialogue Security type column which contained numeric values should be deleted and the references should be to the Dialogue Abstract values. ix Signalling of use of sDS on receipt of an Indication or Confirmation The draft requirements relied on decoding the User Data parameter as an ATNsdsAPDU element and determine if an sdsExchangeData element is present for an Indication or Confirmation. The Dialogue Service was invoked with the Security Requirements Parameter set to “No Security” for a Request or Response. The group decided that it would be better to have the Security Requirements Parameter carried through by the ULCS and IPS Dialogue Service. This may require an Amendment Proposal to Edition 2 of the ULCS. x Making the sDS independent of Context Management The current approach to security is to exchange keying data during the Context Management exchange and pass the key derivation parameters to other applications (i.e. CPDLC and ADSC). Public keys for these applications are passed as application data in the Logon Response message. It was decided that each application would independently exchange keying data during dialogue establishment, that is, CM CPDLC and ADS-C would invoke the dialogue service with the Security Parameter having an abstract value of “Secured Dialogue Supporting Key -5- ACP-WGW2 WP-013 Management”. xi Sharing of Key agreement data across multiple instances of an application. It was decided that key agreement data could be shared across multiple instances of an application in a particular domain. For example, all CPDLC ground applications could use a shared key. Subsequent dialogues by an ATN application of the same type (e.g. the CPDLC application) in the same domain may initiate a new dialogue using key agreement data exchanged during the initial dialogue. This operation is signalled by the domainFlag element in the initial exchange. xii Reinstate other security requirements in Edition 3 of Doc 9880. The question came up if other security requirements (e.g. IDRP Air-Ground Security) should be reinstated in Edition 3. The group was provided with the Link 2000+ Programme “Generic Requirements for a Link 2000+ Air/Ground Communications Service Provider (ACSP)” in which there are requirements that an “ACSP’s Air/Ground router(s) shall never propagate to a ground adjacency (AINSC or ATSC fixed) any route prefixes received from an aircraft in IDRP UPDATE PDUs, except for those carrying the aircraft’s own RDI route prefix.” This requirement will help protect the ground routing database although there is not a strong identity check. The aircraft is not protected but recall that the IDRP requirements for authentication were unilateral and optional for the aircraft to authenticate the ground. The tentative decision of the group was that other security requirements would not be reinstated. xiii Should the MAC tag length be extended to 64-bit tags There was discussion on whether to extend the HMAC tag length to 64 bits. The group was informed that NIST SP 800-107-rev1 (section 5.3.3) requires that an HMAC tag be no less than 32 bit. 800-107 further states “a low bandwidth channel…might use 32-bit MacTags.” It was therefore decided to stay with 32-bit tags. xiv ATN Security Services Concept of Operation (ConOps) document was discussed to include sDS approach, and to develop security scenarios such as Aircraft flying in secured and non-security domains, Ground initiated, Air initiated, and backward compatibility etc. Mike Olive took an action to develop ATN Security Operational Scenarios to reflect sDS approach in the CONOPS document. xv The discussion included use of AeroMACS, OSI and IP communication stacks. ACP-WGW2 WP-013 -6- CP SDS SWG-1 – Brussels, Belgium: 29th – 30th April 2015 LIST OF ATTENDEES Nominated By Name Business Phone E-mail Address State France United States United States United States United States International Organization EUROCONTROL Industry Organization AIRTEL Frederic Picard Vic Patel Tom McParland Mike Olive Madhu Niralu Liviu Popescu Santi Ibarz 1-609-485-5046 1-609-425-4410 1-410-964-7342 1-319-263-8247 3227293757 [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected]
© Copyright 2026 Paperzz