ACP-WG M-13/WP-20
International Civil Aviation Organization
WORKING PAPER
Aeronautical Communication Panel
Working Group M – Maintenance
November 18-21, 2008
Montreal Canada
Approach
for
Air-Ground Security
in
Doc 9880
Prepared by: FAA, ATO-P, AJP 1740
Agenda Item 2 (b)
SUMMARY
This paper proposes incorporating air-ground security provisions into Doc 9880 using the
IETF Internet Key Exchange version 2 (IKEv2) protocol for key establishment in place
of the Doc 9705 procedure using Context Management. This would be the same airground key establishment method specified in Doc 9896 for the ATN IPS. This paper
also proposes using a “Secure Mode” application approach which adds an authentication
tag to application messages in place of the Doc 9705 procedure where security is in the
Upper Layer Communication Service (ULCS). The working group is invited to
consider the proposed approach.
1
1. Introduction
This paper proposes incorporating security provisions into Doc 9880 using the IETF
Internet Key Exchange version 2 (IKEv2) protocol for key establishment in place of the
Doc 9705 procedure using Context Management. This paper also proposes using a
“Secure Mode” application approach which adds the authentication tag to application
messages in place of the Doc 9705 procedure where security is in the Upper Layer
Communication Service (ULCS).
2. Background: Doc 9705 Air-Ground Security
Figure 1 depicts the method of air-ground security in Doc 9705. With the Doc 9705
approach, keys are established during Context Management for other applications.
6. Aircraft derives
Shared CM Session Key
1. Aircraft Signs CM Logon
Message
Airborne CM
Airborne CPDLC
5. Ground CM sends:
it's Public Key Certificate
and CPDLC's public key
in a CM Response Message
with a
Message Authentication Code
2. Aircraft Sends
Signed CM Logon
Message
3.Ground CM
retrieves Aircraft’s
CM Public Key
Certificate and
authenticates the
CM Logon
Message.
It also retrieves the
CPDLC Public Key
Certificate
10. Aircraft CPDLC derives
Shared CPDLC Session Key
7. Aircraft authenticates CM
Response Message
Ground
Context
Management
(CM)
8. Ground CPDLC retrieves sessionunique parameters to derive a Shared
CPDLC Session Key
11. CPDLC Start and
subsequent Messages sent
with a
Message Authentication Code
Ground
CPDLC
9. Ground CPDLC derives a
Shared
CPDLC Session Key
4. Ground CM derives
Shared CM Session Key
Figure 1: Doc 9705 Air-Ground Security
The process begins (step 1) with a logon message when the aircraft CM application
invokes the ULCS indicating that key establishment is to be performed. This will cause
2
the dialogue service to invoke the Security Application Service Object (SASO) which in
turn invokes the Security Service Object (SSO) which will add a digital signature to the
logon message. The ULCS architecture with Doc 9705 security is depicted in Figure 2.
Air/Ground User Application
Air/Ground AE
Control
Function
(CF)
System
Security
Object
(SSO)
Air/Ground
Application Service
Element (ASE)
Security
Application Service
Object (SASO)
ASE
Service
Boundary
Dialogue
Service
Boundary
Association Control
Service Element
(ACSE)
Figure 2: Doc 9705 ULCS Security Architecture
The signed message (step 2) is sent to the ground CM application. The Ground CM
application (step 3) retrieves the Aircraft’s CM Public Key Certificate and using the
public key validates the signed logon message. The Ground CM also retrieves the
CPDLC Public Key Certificate. Using the Aircraft’s CM public key and its own CM
private key, the Ground CM derives a shared CM session key (step 4) using the DiffieHellman key agreement technique. The Ground CM then sends its public key certificate
and the CPDLC public key in a the logon response message (step 5). The message is
tagged with a Message Authentication Code using the shared CM session key. Note that
the CPDLC public key is sent as part of the application message. The message also
contains a set of session unique parameters. The Aircraft derives the shared CM session
key (step 6) using its own CM private key and the Ground CM’s public key. The Aircraft
authenticates the logon response message (step 7). At this point the Aircraft and Ground
CMs have authenticated one another and the Aircraft is in possession of the Ground
CPDLC public key.
When the Ground CPDLC initiates a secure CPDLC session with the Aircraft, it first
retrieves the session unique parameters and derives a CPLDC session key (step 9) using
the Aircraft’s CPDLC public key and its own CPDLC private key. The Aircraft also
derives this session key using its own CPDLC private key and the Ground CPDLC public
3
key (step 10). The CPDLC start and subsequent messages (step 11) are tagged by the
sender with a Message Authentication Code that is verified by the receiver.
3. Doc 9880 Approach to Air-Ground Security
3.1 The Internet Key Exchange Version 2
The approach proposed for Doc 9880 security is to use IKEv2 to exchange keys rather
then the CM exchange method defined in Doc 9705. Figure 3 depicts the messages
exchanged with IKEv2.
IKE_SA_INIT
HDR,SAi,KEi,Ni
Notation
HDR,SAr,KEr,Nr,
[CERTREQ]
AUTH – Authentication Data
CERT – Public Key Certificate
CERTREQ – Certificate Request
HDR – Header
ID_I, ID_R – Initiator, Responder Identifier
KE – Key Exchange (DH Public Values)
Ni, Nr – Initiator/Responder Nonce
SAi, SAr – Intiator/Responder
Security Association
TSi, TSr – Initiator, Responder
Traffic Selector
IKE_SA_AUTH
HDR, SK(ID_I,[CERT], [CERTREQ]
[ID_R], AUTH,SAi,TSi,TSr)
HDR, SK(ID_R,[CERT],AUTH,
SAr2,TSi, TSr)
Figure 3: IKEv2 Exchanges
In the IKE_SA_INIT exchange the initiator and responder exchange Security Association
(SA) payloads, Key Exchange (KE) payloads containing Diffie-Hellman public values,
and Nonces (N). The SA payload identifies what cryptographic suite is to be used for the
IKE_SA. The KE and N values are used to generate a shared key SKEYSEED from
which other keys are derived. The derived keys are used in the IKE_SA_AUTH
exchange to authenticate the identity of the Aircraft and Ground CPDLC entities and to
authenticate subsequent messages under the Security Association.
In the IKE_SA_AUTH exchange the identities (ID) of the SA entities are exchanged. SA
payloads for the CHILD_SA are exchanged as well as traffic selectors (TS) which may
be used to indicate what types of traffic are to be protected. The AUTH payload contains
the type of authentication method used and the authentication data. IKEv2 permits
authentication using digital signatures, shared secrets, or using Extensible Authentication
Protocol (EAP) methods.
4
IKEv2 is an update to the previous IKEv1 version. IKEv2 is considered to be a
significant improvement to the IKEv1 protocol which was available when the security
provisions of Doc 9705 were developed. IKEv1 was specified in three separate
documents. IKEv1 had 8 exchange types for the first phase of operations and could
operate in two modes. Along with the latency to establish Security Associations (SAs),
this led to interoperability problems. It was also vulnerable to certain Denial of Service
attacks.
3.2 Air-Ground Security using IKEv2
Figure 4 depicts the proposed Doc 9880 approach to air-ground security.
3. Aircraft IKEv2 derives a
shared CPDLC Session Key
Using IKE_SA_INIT paremeters
Airborne CPDLC
4. CPDLC Start and
subsequent Messages sent
with a
Message Authentication Code
1 Aircraft and
Ground IKEv2 entities exchange
IKE_SA_INIT
And
IKE_SA_AUTH
Messages
Ground
CPDLC
2. Ground IKEv2 derives a
shared CPDLC Session Key
Using IKE_SA_INIT paremeters
Figure 3: Air-Ground Security with IKEv2
As depicted in (step 1) the Aircraft and Ground IKEv2 entities will first exchange
IKE_SA_INIT and IKE_SA_AUTH messages in accordance with the IKEv2 protocol.
This may be accomplished using pre-determined cryptographic suites for IKEv2 and for
application authentication and a pre-determined set of traffic selectors for ATN
application messages. It is recommended that the same suite of cryptographic protocols
specified in Doc 9896 for the ATN IPS be used. The Aircraft IKEv2 and Ground IKEv2
entities may each (steps 2 and 3) derive a shared CPDLC Session Key using the
SKEYSEED value which was derived from the public Diffie-Hellman values (KE) and
Nonces (N) of the two entities. The CPDLC start and subsequent messages (step 4) are
tagged by the sender with a Message Authentication Code (MAC) that is verified by the
5
receiver. Note that authentication using a keyed MAC is the same approach as was in
Doc 9705 security. However, in this case it is proposed that this not be performed in the
ULCS but rather that a “Secure Mode” version of CPDLC be used where the tag is added
and checked by the CPDLC ASE. Thus the ULCS would not need to be modified to use
the SASO and SSO depicted in Figure 2. Figure 5 depicts the protocol architecture for
the proposed approach for the CPDLC application. In the Internet Protocol Suite
environment IKEv2 runs over UDP. It is recommended that this same approach be used
in the OSI environment with UDP running over CLNP instead of IP.
SM CPDLC
ULCS
FB Presentation
IKEv2
FB Session
UDP
TP4
IDRP
CLNP
Figure 5: Protocol Architecture using IKEv2 and “Secure Mode” CPDLC
The use of IKEv2 and secure mode applications also has the benefit that Context
Management would not require modification to support air-ground security. Note
however that CM itself could be secured following the same approach of using IKEv2 to
establish keys and added a keyed MAC tag to its application messages.
4. Recommendation
1) It is recommended that the Working Group adopt the proposed approach to AirGround security described in this working paper.
If agreed, then it is recommended that:
2) The technical provisions for the security section of Doc 9880 be developed primarily
by reference to Internet Engineering Task Force (IETF) Request for Comment (RFC)
specifications.
3) The Doc 9705 security provisions in the ULCS not be brought into Doc 9880.
6