Report of SDS

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]