ACPWGM16/WP-16
International Civil Aviation Organization
17 May 2010
WORKING PAPER
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.
ACP-WGM16/WP-16
1.
-2-
INTRODUCTION
1.1
This working paper describes a “Secure Dialogue Service (SDS)” as an implementation of the ATN AirGround 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:
“Complexity
Implementers 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 SubVolume 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.”
-3-
2.1.2
ACP-WGM16/WP-16
ULCS Security Architecture
Figure 2-1 depicts the ULCS Security Architecture defined in Doc 9880.
Application User
ATN-App AE
CF
ATN-App
ASE
Dialogue Service Boundary
Security ASO
SSO
ACSE
SESE
Presentation Service Provider
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.
-4-
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” sublayer (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.
Application User
ATN-App AE
CF
ATN-App
ASE
Secure Dialogue Service Boundary
SSO
Secure Dialogue Svc
Doc 9705 Ed 2 Dialogue Service Boundary
ACSE
Presentation Service Provider
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,
sdsProtectSign ATNProtectSign,
-5-
ACP-WGM16/WP-16
... }
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 integer
counter
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.
-6-
ACP-WGM16/WP-16
ATN-App ASE
D-START req (Secured Dialogue Supporting
Key Management)
Dialogue Service Boundary
CF
SA-START req
SSO-Sign
SASO
SSO
SE-TRANSFER req
SESE
A-ASSOCIATE req
ACSE
ATN-App ASE
SSO-Sign
SSO
sD-START req (Secured Dialogue Supporting
Key Management)
Secure Dialogue Service Boundary
SECURE DIALOGUE
SERVICE
D-START req (No Security)
Dialogue Service Boundary
CF
A-ASSOCIATE req
ACSE
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.
-7-
2.3.1.2
ACP-WGM16/WP-16
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 DDATA 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.
3.1
ACTION BY THE MEETING
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.
ACP-WGM16/WP-16
-8-
APPENDIX A
SecuredATNULs-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 FROM
SeseAPDUs seseAPDUs
-- From other ATN Security modules -securityExchanges, secATN-AS FROM
ATNObjectIdentifiers { iso(1) identified-organization(3)
icao(27) atn(0) objectIdentifiers(0) }
SecATN-SEObjects FROM
ATNSecurityExchanges 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
AuthenticationFramework { joint-iso-ccitt ds(5) module(1)
-9-
ACP-WGM16/WP-16
authenticationFramework(7) 3 }
SECURITY-EXCHANGE {}, SEC-EXCHG-ITEM {} FROM
Notation 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 FROM
ATN-PKI atnPKI
-- Defined in Sub-Volume VIII
ECDSA-Sig-Value FROM
ATN-PKI-Explicit atnPKI-explicit
-- Defined in Sub-Volume VIII
;
atnEstablishSE SECURITY-EXCHANGE ::= {
SE-ITEMS
{atnEstablish}
IDENTIFIER local : 1 }
atnEstablish SEC-EXCHG-ITEM ::= {
ITEM-TYPE ATNEstablish
ITEM-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 ATNProtectSign
ITEM-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 integer
counter
INTEGER (0..MAX),
-- unsigned, unconstrained integer
... } OPTIONAL,
- 10 -
ACP-WGM16/WP-16
value
CHOICE {
ecdsa-Signature
hmac-Tag
... }
ECDSA-Sig-Value,
OCTET STRING (SIZE (4, ...)),
}
SecATN-SEObjects SECURITY-EXCHANGE ::=
{atnEstablishSE | atnProtectSignSE, ... }
END -- End of ASN.1 module
- 11 -
ACP-WGM16/WP-16
APPENDIX B
ATN-App ASE
D-START ind (Secured Dialogue Supporting
Key Management)
Dialogue Service Boundary
CF
SA-START ind
SSOSignCheck
SASO
SSO
SE-TRANSFER ind
SESE
A-ASSOCIATE ind
ACSE
ATN-App ASE
SSOSignCheck
SSO
sD-START ind (Secured Dialogue Supporting
Key Management)
Secure Dialogue Service Boundary
SECURE DIALOGUE
SERVICE
D-START ind (No Security)
Dialogue Service Boundary
CF
A-ASSOCIATE ind
ACSE
Figure B-1: D-START Indication
- 12 -
ACP-WGM16/WP-16
ATN-App ASE
D-START rsp (Secured Dialogue Supporting
Key Management)
Dialogue Service Boundary
CF
SA-START rsp
SSO
SASO
SSO-GetCertificatePath
SSO-Sign
SE-TRANSFER req
SESE
A-ASSOCIATE rsp
ACSE
ATN-App ASE
SSO
SSO-GetCertificatePath
SSO-Sign
sD-START rsp (Secured Dialogue Supporting
Key Management)
Secure Dialogue Service Boundary
SECURE DIALOGUE
SERVICE
D-START rsp (No Security)
Dialogue Service Boundary
CF
A-ASSOCIATE rsp
ACSE
Figure B-2: D-START Response
- 13 -
ACP-WGM16/WP-16
ATN-App ASE
D-START cnf (Secured Dialogue Supporting
Key Management)
Dialogue Service Boundary
CF
SA-START cnf
SSOSignCheck
SASO
SSO
SE-TRANSFER ind
SESE
A-ASSOCIATE cnf
ACSE
ATN-App ASE
SSOSignCheck
SSO
sD-START cnf (Secured Dialogue Supporting
Key Management)
Secure Dialogue Service Boundary
SECURE DIALOGUE
SERVICE
D-START cnf (No Security)
Dialogue Service Boundary
CF
A-ASSOCIATE cnf
ACSE
Figure B-3: D-START Confirmation
- 14 -
ACP-WGM16/WP-16
ATN-App ASE
D-DATA req (Secured Dialogue)
Dialogue Service Boundary
CF
SA-SEND req
SSOProtectSign
SASO
SSO
SE-TRANSFER req
SESE
ACSE
ATN-App ASE
sD-START req (Secured Dialogue)
SSOProtectSign
SSO
SECURE DIALOGUE
SERVICE
Secure Dialogue Service Boundary
D-START req (No Security)
Dialogue Service Boundary
CF
ACSE
Figure B-4: D-Data Request
- 15 -
ACP-WGM16/WP-16
ATN-App ASE
D-DATA ind (Secured Dialogue)
Dialogue Service Boundary
CF
SSOProtect
SignCheck
SA-SEND ind
SASO
SSO
SE-TRANSFER ind
SESE
ACSE
ATN-App ASE
SSO
SSOProtect
SignCheck
sD-DATA ind (Secured Dialogue)
SECURE DIALOGUE
SERVICE
Secure Dialogue Service Boundary
D-DATA ind (No Security)
Dialogue Service Boundary
CF
ACSE
Figure B-5: D-DATA Indication