/
International Civil Aviation Organization
WORKING PAPER / ACP-WG M-13/WP-20

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 air-ground 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. 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.

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 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.

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 Diffie-Hellman 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 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.

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.

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.

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 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.

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 Air-Ground 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.

1