AERONAUTICAL COMMUNICATIONS PANEL (ACP)

16th MEETING OF WORKING GROUP M (Maintenance)

Paris, France 17-19 May 2010

Agenda Item 3a: ATN/OSI Document 9880 Update Status – Security Updates

Secure Dialogue Service

Prepared by: FAA

Presented by: Tom McParland

SUMMARY

This working paper proposes a realization of the ATN Security Solution as a Secure Dialogue Service which is placed above the “standard” dialogue service. This is proposed as an alternative realization to that defined in the current version of Doc 9880 where the ATN Security Solution is realized in the Upper Layer Communications Service (ULCS).

ACTION

The working group is invited to consider the alternate realization described in this working paper.

International Civil Aviation Organization

WORKING PAPER

ACPWGM16/WP-1617 May 2010

ACP-WGM16/WP-16

1. INTRODUCTION

1.1 This working paper describes a “Secure Dialogue Service (SDS)” as an implementation of the ATN Air-Ground Application Security Solution. The Secure Dialogue Service is an alternative to the Upper Layer Communications Service (ULCS) implementation as specified in Doc 9880, Part III, Chapter 2.

2. DISCUSSION

2.1 ACP Working Paper N04 WP 36 presented by EUROCONTROL at the 4th Meeting of Working Group N identified several issues with the realization of the ATN Security Solution in the ULCS. One key issue was complexity as described in the below excerpt:

“ComplexityImplementers have complained that the ATN security provisions are "too complex." However, other implementers have successfully developed conformant software.

Part of the "complexity" perception comes from the inclusion of detailed cryptographic parameters in Sub-Volume VIII, plus the use of security terminology and algorithms that may be unfamiliar to many communication product vendors.

Another perceived problem is the convoluted structure of the Control Function in Sub-Volume IV. In fact there are two CFs;

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.

The situation is exacerbated by seemingly complex ASN.1 structures in Sub-Volume IV, particularly in the security exchange data types constructed by the ISO-standard SESE. "Information Object" definitions SECURITY-EXCHANGE and SEC-EXCHG-ITEM are imported from the OSI security framework; they are not widely understood. The specification of SESE APDUs uses advanced ("difficult") ASN.1 constructs, which may not be supported by some ASN.1 toolkits. However, the Sub-Volume IV Guidance Material (Draft Doc 9739 Ed 2) explains how the ASN.1 types are encoded as straightforward bit sequences.

It might be possible to simplify the structure of the security provisions by eliminating some of the abstract service invocations. For example, the Security ASO could be eliminated, the SSO could be invoked "inline" from the DS-CF, and the final PDU constructed directly rather than by invoking the SESE. This would certainly make the processing easier to follow, though it would destroy the modular structure of the specification, which is based on OSI Application Layer Structure object-oriented principles.”

2.1.1 Complexity of Cryptographic Parameters

To deal with complexity from inclusion of detailed cryptographic parameters an Amendment Proposal is being processed to “Refer to SEC 2 Standards for ECC Domain Parameters.”

2

ACP-WGM16/WP-16

2.1.2 ULCS Security Architecture

Figure 2-1 depicts the ULCS Security Architecture defined in Doc 9880.

Figure 2-1: ULCS Security Architecture

2.1.2.1 Control Function

As noted above in the ULCS realization of the ATN security solution, there is an extended outer dialogue service control function to handle interaction between the App ASE, the Security ASO, ACSE, and the supporting service. This means that in order to implement the ATN Security Solution in the ULCS, implementers will have to replace the implementation of their ULCS with a more complex one.

2.1.2.2 Use of the Security Exchange Service Element

The Security Exchange Service Element (SESE) defines the general form of an abstract syntax for use in transferring protocol items in a security exchange. The use of SESE introduces complex ASN.1 structures for SESE exchange items. The ASN.1 module is listed in Appendix A. In addition to complexity the SESE exchange items add 48 bits of overhead to each secure message exchanged.

2.1.2.3 Use of the Association Control Service Element

The Association Control Service Element (ACSE) supports the establishment and termination of application associations. The association establishment procedure can optionally include the exchange of authentication information. This option is used in the ULCS realization of the ATN Security Solution. Thus, whereas the Doc 9705 Edition 2 ULCS used ACSE to simply establish application associations, in the Doc 9880 ULCS supporting security, the authentication mechanism of ACSE is used. This further adds to the complexity of the ULCS.

3

ACP-WGM16/WP-16

2.2 Description of the Secure Dialogue Service

The approach for the alternate realization proposed in this working paper is to introduce a “Secure Dialogue Service” sub-layer (previously known as the “Security Shim”). The Secure Dialogue Service would be inserted between the Application ASE and the “standard” dialogue service as defined in Doc 9705 Edition 2 and as currently implemented in the Link 2000+ program. Note that from the application perspective the Secure Dialogue Service presents the Doc 9880 Dialogue Service; therefore, the Doc 9880 versions of CPDLC and CM would not require change.

Figure 2-2: Secure Dialogue Service Architecture

The Secure Dialogue service would essentially append the required security items directly to Application Protocol Data Units (APDUs).

2.2.1 ASN.1 Elements

Although not a formal ASN.1 module, the ASN.1 elements listed below demonstrate the concept of directly appending security items to APDUs. A simple set of ASN.1 structures (ATNsdsAPDU and ATNsdsExchange) are introduced to frame the secure message. The appended items are either the ATNEstablish structure or the ATNProtectsign structure. These items are the same as defined in Appendix A but without the SESE structures. The ATNEstablish and ATNProtectsign elements are generated by the Security Service Object (SSO).

ATNsdsAPDU ::=SEQUENCE {sdsAPDU User-data OPTIONAL,sdsExchangeData ATNsdsExchange OPTIONAL,... }

ATNsdsExchange ::= CHOICE {sdsEstablish ATNEstablish,

4

ACP-WGM16/WP-16

sdsProtectSign ATNProtectSign,... }

ATNEstablish ::= SEQUENCE {atnCertificates SEQUENCE OF ATNCertificates OPTIONAL,atnSignature ATNAppendix,... }

ATNProtectSign ::= SEQUENCE {unprotected OCTET STRING OPTIONAL,appendix ATNAppendix,... }

ATNAppendix ::= SEQUENCE {algorithmId AlgorithmIdentifier OPTIONAL,validity CHOICE {

timeField ATNSecurityDateTime ,random INTEGER (0..4294967295),

-- 32-bit unsigned integercounter INTEGER (0..MAX),

-- unsigned, unconstrained integer... } OPTIONAL,

value CHOICE {ecdsa-Signature ECDSA-Sig-Value,hmac-Tag OCTET STRING (SIZE (4, ...)),... }

}

2.3 Differences between the Secure Dialogue Service and the ULCS Realization

This section contains an example to contrasts the two realizations. The example is that of an air-initiated D-START exchange where “Secured Dialogue Supporting Key Management” is the abstract value for the security parameter. This would be a secured CM-Logon request.

2.3.1 Example of ULCS and Secure Dialogue Service Primitive Processing (D-START Request)

Figure 2-3 depicts processing of the D-START Request for the ULCS and Secure Dialogue Service realizations of the ATN Security Solution.

5

ACP-WGM16/WP-16

Figure 2-3: D-START Request

2.3.1.1 ULCS D-START Request

When the ULCS control function receives the D-START Request it forms the Calling Entity ID and the Called Entity ID from the D-START parameters. The control function then invokes an SASO SA-START Request with the Entity IDs and the D-START User Data which contains the CM-Logon Request.

The SASO control function invokes the SSO-Sign function to generates a Signature-appendix. The SASO maps the Calling Entity ID and Called Entity ID onto the Source Peer and Destination Peer of SSO-Sign. In this case the SSO-Sign function builds the ATNEstablish element without the atnCertificates sub-element. The atnSignature sub-element contains an ATNAppendix. The ATNAppendix will contain a validity sub-element which in this case contains the timeField and a value sub-element which contains an ecdsa-Signature. The SASO then invokes the SE-TRANSFER request primitive to build a Security Exchange Item which includes the ATNEstablish element built by SSO-Sign plus other items required to implement an SESE element in its general form.

Control then returns to the outer control function which invokes the A-Associate Request service of ACSE to construct an AARQ APDU. In this case ACSE will generate an AARQ APDU with the ACSE Requirements option set to indicate “Authentication” and the Authentication-value containing the security exchange item built in the SASO. The AARQ APDU is then passed to the Presentation Service to complete the ULCS processing.

6

ACP-WGM16/WP-16

2.3.1.2 Secure Dialogue Service D-START Request

When the Secure Dialogue Service receives the D-START Request it forms the Source Peer and Destination Peer from the D-START parameters using the same logic as the ULCS control function. The Secure Dialogue Service then invokes SSO-Sign to build the ATNEstablish element. The Secure Dialogue Service next builds the ATNsdsAPDU, in effect, appending ATNEstablish to User Data. The Secure Dialogue Service then simply invokes the “standard” Dialogue Service D-START primitive but with the abstract value “No Security” for the Security Requirements parameter and with the ATNsdsAPDU as User Data. The “standard” Dialogue Service will process the D-START request including invoking ACSE; however, in this case ACSE will not use the Authentication option of ACSE.

2.3.2 Other Dialogue Service Primitives

Appendix B contains diagrams which depict the processing flows for the remaining D-START primitives and for D-DATA Request and Indication exchanges. In each case the main difference is that security information is transferred as part of the ATNspsAPDU structure. This is in contrast to carrying this information is SESE Exchange Items and using the Authentication option of ACSE.

2.4 Use of the Secure Dialogue Service over the IP Dialogue Service

In ICAO Doc 9896, the IP Dialogue Service is defined. The IP Dialogue Service preserves the dialogue service abstract interface to ATN applications. By inserting the Secure Dialogue service over the IP Dialogue Service, the ATN Security Solution can be applied to a future TCP/IP environment.

2.5 Ground System Architectural Advantages of the Secure Dialogue Service

With the Secure Dialogue Service security may be added in Automation Systems which operate over a TCP/IP stack and interface to a Data Link Front End Processor. This architecture has been implemented in Link 2000+ and is planned for the FAA’s Data Comm program.

3. ACTION BY THE MEETING

3.1 The ACP WG-M is invited to:

1. Review the recommended approach as presented in this Working Paper and provide comments and feedback regarding the approach as described.

3.2 The FAA recommends acceptance of these changes and requests endorsement by the Working Group of to develop an Amendment Proposal to incorporate the recommended changes into Doc 9880.

7

ACP-WGM16/WP-16

APPENDIX A

1SecuredATNULs-Abstract-Syntax { iso(1) identified-organization(3) icao(27)atn-security-requirements(5) modules(1) abstract-syntax(2) }

DEFINITIONS AUTOMATIC TAGS ::= BEGIN

-- EXPORTS ALL --

IMPORTS-- From GULS --seseAPDUs FROM

ObjectIdentifiers { joint-iso-ccitt genericULS(20) modules(1)objectIdentifiers(0) }

SESEapdus, NoInvocationId FROMSeseAPDUs seseAPDUs

-- From other ATN Security modules --securityExchanges, secATN-AS FROM

ATNObjectIdentifiers { iso(1) identified-organization(3)icao(27) atn(0) objectIdentifiers(0) }

SecATN-SEObjects FROMATNSecurityExchanges securityExchanges

;

securedATNULs-Abstract-Syntax ABSTRACT-SYNTAX ::={

SESEapdus{

{SecATN-SEObjects},{NoInvocationId}

} IDENTIFIED BY secATN-AS}END

ATNSecurityExchanges { iso(1) identified-organization(3) icao(27)atn-security-requirements(5) modules(1) securityExchanges(1) }

DEFINITIONS AUTOMATIC TAGS ::= BEGIN

-- EXPORTS ALL --

IMPORTS-- From other ISO/ITU-T standards --notation FROM

ObjectIdentifiers { joint-iso-ccitt genericULS(20) modules(1)objectIdentifiers(0) }

AlgorithmIdentifier FROM

8

ACP-WGM16/WP-16

AuthenticationFramework { joint-iso-ccitt ds(5) module(1)authenticationFramework(7) 3 }

SECURITY-EXCHANGE {}, SEC-EXCHG-ITEM {} FROMNotation notation

-- From other ATN Security modules --atnPKI, atnPKI-explicit FROM

ATNObjectIdentifiers { iso(1) identified-organization(3)icao(27) atn(0) objectIdentifiers(0) } -- Defined in 9.2.1.3

ATNCertificates, ATNSecurityDateTime FROMATN-PKI atnPKI -- Defined in Sub-Volume VIII

ECDSA-Sig-Value FROMATN-PKI-Explicit atnPKI-explicit -- Defined in Sub-Volume VIII

;

atnEstablishSE SECURITY-EXCHANGE ::= {SE-ITEMS {atnEstablish}IDENTIFIER local : 1 }

atnEstablish SEC-EXCHG-ITEM ::= {ITEM-TYPE ATNEstablishITEM-ID 1 }

ATNEstablish ::= SEQUENCE {atnCertificates SEQUENCE OF ATNCertificates OPTIONAL,atnSignature ATNAppendix,... }

atnProtectSignSE SECURITY-EXCHANGE ::= {SE-ITEMS {atnProtectSign}IDENTIFIER local : 2 }

atnProtectSign SEC-EXCHG-ITEM ::= {ITEM-TYPE ATNProtectSignITEM-ID 1 }

ATNProtectSign ::= SEQUENCE {unprotected OCTET STRING OPTIONAL,appendix ATNAppendix,... }

ATNAppendix ::= SEQUENCE {algorithmId AlgorithmIdentifier OPTIONAL,validity CHOICE {

timeField ATNSecurityDateTime ,random INTEGER (0..4294967295),

-- 32-bit unsigned integercounter INTEGER (0..MAX),

9

ACP-WGM16/WP-16

-- unsigned, unconstrained integer... } OPTIONAL,

value CHOICE {ecdsa-Signature ECDSA-Sig-Value,hmac-Tag OCTET STRING (SIZE (4, ...)),... }

}

SecATN-SEObjects SECURITY-EXCHANGE ::=

{atnEstablishSE | atnProtectSignSE, ... }

END -- End of ASN.1 module

10

ACP-WGM16/WP-16

APPENDIX B

Figure B-1: D-START Indication

11

ACP-WGM16/WP-16

Figure B-2: D-START Response

12

ACP-WGM16/WP-16

Figure B-3: D-START Confirmation

13

ACP-WGM16/WP-16

Figure B-4: D-Data Request

14

ACP-WGM16/WP-16

Figure B-5: D-DATA Indication

15