| Internet-Draft | Use Case Validation Request Extension | May 2022 |
| Segers & Kopman | Expires 27 November 2022 | [Page] |
This document describes a civil aviation, air-to-ground communication use case for the Path Validation extension to Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) using the Server-based Certificate Validation Protocol (SCVP).¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 27 November 2022.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
In a digital aviation environment, there is a need for interoperability and cyber resilience. Establishing trusted communications presents additional challenges when it is integrated at a global level.¶
The International Civil Aviation Organisation (ICAO) Work Group I (WG-I) of the Communication Panel has standardized the use of DTLS for end to end information security protection between the aircraft and the ground user system.¶
The ICAO Trust Framework Study Group (TFSG) has worked to develop policy and guidance material for a global and interoperable International Aviation Trust Framework (IATF) that will enable trusted ground-ground, air-ground, and air-air exchange of information. This trust framework is based on a Public Key Infrastructure (PKI) with a cross-certified Certificate Authority (CA) hierarchy and is designed to map commercial aviation identity and access requirements to a common set of operating rules. These rules are governed by the trust framework Certificate Policy (CP).¶
The Federal Aviation Administration (FAA) and European Organisation for the Safety of Air Navigation (EUROCONTROL) collaborated under Coordination Plan 1.8 between FAA Next Generation Air Transportation System (NextGen) and Single European Sky ATM Research (SESAR) Deployment Manager (SDM) to prototype a solution for secure ground-to-ground communications based on this trust framework. This prototype demonstrated the viability of leveraging the SCVP for identity validation. The SCVP offloads the complexity of certificate path discovery and validation from the client, which is establishing trust to a common server. This reduces the computational load and complexity of the client. It also ensures that policies are consistently applied across all clients by moving the policy validation to a common server.¶
SCVP has been used for validating ground-to-ground communications and can be leveraged for air-to-ground communications. The additional challenges in air-to-ground communications including limited bandwidth and higher latency must be considered in development of a solution. These limitations can be addressed by enabling validation without requiring the aircraft to have direct communication with the SCVP responder. This paper proposes offloading the SCVP request to the ground-based server and providing the aircraft with the outcome of this interaction. A use case presentation [path_val_use_case] of the proposed path validation extension to TLS as presented to the ICAO Internet Protocol Suite (IPS) Security Subgroup is available.¶
To encourage comprehension necessary for adoption of the TLS Extension for Path Validation by the intended user community, the civil aviation community's norms are respected herein. The terms listed below are from that community.¶
A significant step in establishing security in air-to-ground communications is for the aircraft to validate the ground server's identity. Protocols, such as DTLS, use certificates to exchange identity information. Validation of trust in the ground server's identity is done by constructing and validating a trust chain from the ground server's end-entity certificate to a root of trust. This can be done in two ways. Implementation of certificate path construction and validation can be done onboard the aircraft. This approach requires loading each aircraft with the trust anchors in use by all ground servers communicating with the aircraft worldwide and any intermediated trust anchors between the ground server certificate and the root. Validation of identity onboard the aircraft also requires regularly uploading revocation lists for validating the certificates. These steps place a significant burden on the aircraft. Alternatively, the responsibility of certificate path construction and validation can be delegated to a trusted SCVP responder. In this case, the aircraft only requires awareness of a single trust anchor to verify the SCVP response is signed by a trusted SCVP responder.¶
The resource limitations of air-to-ground communications necessitates consideration of bandwidth usage and number of round-trips. To address these limitations, the overhead of the SCVP request can be performed by the ground-based server. The outcome of the SCVP request can be provided to the aircraft.¶
The TLS and DLTS extension framework defines an extension for clients to request the revocation status of the server's certificate for Section 3 of TLS 1.2 [RFC6066] and TLS 1.3 [RFC8446]. This status request extension offloads the gathering of certificate revocation information from a TLS/DTLS client to a TLS/DTLS server. This technique is widely used to provide Online Certificate Status Protocol (OCSP) responses to the client, but it has some limitations. OCSP responses and certificates are needed for each step in the trust chain. This can result in a very large data exchange. OCSP only provides revocation information, trust must still be determined by the client.¶
SCVP, in contrast, can provide a single response for the full path building and validation. Additionally, the SCVP response does not require the full details of the path in the response. Therefore, SCVP can offload more processing from the client and provide the outcome in a much smaller response than OCSP. A new TLS/DTLS extension should be defined for SCVP validation request which can leverage the concepts behind the OCSP status request extension.¶
In air-to-ground communications, the aircraft initiates a DTLS connection with a ground-based server. The aircraft will optionally include a SCVP validation request extension in the Client Hello message. The extension data will contain an PathValidationRequest consisting of an optional list of SCVP Responder URIs, an optional list of trust anchors, and an optional list of SCVP settings used to convey client preferences.¶
On receipt of a Client Hello with a validation request extension the ground server will process the request. If the ground server has a cached response matching the aircraft's settings it will use the cached response. If the ground server does not have an appropriate response cached, it will process the PathValidationRequest and create an SCVP Validation Request [RFC5055] for validation of the ground server's TLS certificate. If the aircraft specified SCVP responder URI(s) in its request, the ground server will send the SCVP request to the first reachable SCVP responder in the list. If the aircraft specified a trust anchor, the ground server will include the trust anchor in the SCVP request Validation Policy and send the request to its pre-configured SCVP responder. In both cases, the ground server sends the aircraft a PathValdiationResponse containing the signed SCVP response following the DTLS Certificate handshake message. The aircraft validates that the included SCVP response has been signed by a trusted SCVP responder.¶
In international aviation there is the potential to stand up many CAs and many SCVP responders. These SCVP responders can be at different levels in the trust framework hierarchy. For example, the responders can be at an airline, an Air Navigation Service Provider (ANSP), a region, or at an international (IATF) level. The aircraft can include a list of responders that it trusts, but at a minimum should include the IATF SCVP responder. By setting the IATF SCVP responder as a neutral fall-back, which will be reachable by any member of the trust framework, it is possible to establish trust from anywhere in the world.¶
The use of short-lived certificates has been discussed within the international aviation community to ease the burden of certificate revocation checking onboard the aircraft. The intent is to use short-lived end-entity certificates by ground-based servers so that Certificate Revocation Lists (CRLs) are not needed onboard the aircraft. However, this does not address establishing trust. A certificate path from the ground server's end-entity certificate to an aircraft trust anchor must be constructed and validated. Maintaining or dynamically retrieving all of the intermediate certificates and their revocation information for global aviation communications onboard an aircraft is impractical. Additionally, path validation not only checks revocation status, but also ensures that the certificate is fit for purpose and conforms to profile policies. Whether SCVP is utilized to validate long-lived or short-lived certificates, the security posture and maintenance strategy are the same from the aircraft perspective. This is because the SCVP responder performs the revocation checking as one part of the certificate validation process.¶
SCVP should be used to enable validation of certificates in a complex international aviation ecosystem. The viability of this approach has been demonstrated in a ground-to-ground Proof-Of-Concept. Short-lived certificates are not a viable alternative to SCVP, as even they need chain validation.¶
The SCVP validation request extension is proposed as a mechanism to bring the benefits of SCVP into air-to-ground communications. It will reduce the overhead for the aircraft by offloading the complex path validation to a server and eliminate the need for CRL downloads by the aircraft. Also, by including the SCVP response with the ground-based server's certificate the overhead of the SCVP request is performed by the ground system.¶
IANA considerations for the Path Validation TLS extensions are covered in draft extension [I-D.draft-segers-tls-cert-validation-ext].¶
Security considerations for the Path Validation TLS extensions are covered in draft extension [I-D.draft-segers-tls-cert-validation-ext].¶