Means of Compliance for DRIP Entity Tags as UAS RID Identifiers

1.1. Purpose

This document is written to reference other documents, thus acting as an introduction for Civil Aviation Authorities (CAAs) and their Operators attempting to comply within a given jurisdiction. A CAA MAY override any requirement in this document, but MUST provide the reason and an alternative for their operators to implement. This document offers technical options, with recommendations of defaults for international interoperability.¶

1.2. Background

A registry function including Hierarchical Host Identity Tag (HHIT) Domain Authority (HDA) is required to support Session IDs that can be used by CAAs and other lawfully authorized parties to look up essential safety and security information associated with UAS and their Operators.¶

In the Unmanned Aerial System (UAS) Traffic Management (UTM) context, it is expected that the HDA function will be provided by each UAS Service Supplier (USS). This can be in-house or out-sourced to a service bureau more specialized in cryptographically verifiable identifiers usable to access data and systems on networks. Outside the UTM context, each Operator must still obtain this function from some provider.¶

The HDA function also can support other services related to Session IDs. The DRIP Entity Tag (DET) can act as a Session ID and/or Authentication Key ID, thus HDA functionality in this document assumes both are being provided to registrants (see Section 9.1 for more details). The use of Authentication is mandated in some (e.g. Japan) but not all regions.¶

Each DET is tied to a longer term identifier by its HDA. Typically this identifier is expected to be the UAS Serial Number, however a CAA MAY choose another long term identifier of significance to them.¶

1.3. Scope

Any entity involved in UAS Broadcast RID as per this document:¶

• if that entity uses a Session ID (some participating entities, e.g. HDAs, may not have Session IDs), MUST use a DET for that Session ID.¶
• if that entity participates in DRIP protocol interactions (even if not needing a Session ID), MUST use a DET for the DRIP public key ID.¶
• if that entity requires a strongly cryptographically verifiable IP compatible identifier, MAY use a DET for any other legal purpose.¶
• SHOULD NOT use DET as a locator in physical or logical space (e.g. as a globally routable IPv6 address outside of an overlay network). See Section 8.1 for further details.¶

The archetypal case is a UAS for which the DET serves as both the UAS ID (e.g. in the ASTM [F3411] Basic ID Message as a Type 4, Subtype 1 Specific Session ID) and the Authentication Key ID.¶

DRIP builds upon existing UAS RID standards (ASTM [F3411]) and baseline Means of Compliance (ASTM [F3586]). This document acts as a further Means of Compliance for DETs to be used as Session IDs and/or Authentication Key IDs. This document is intended to be internationally applicable but at the time of first writing the authors have only confirmed compatibility with ASTM [F3586] (and thus US FAA rules).¶

2.1. Additional Definitions

This document makes use of terms (PII, USS, etc.) defined in [RFC9153], [RFC9434] and [RFC9374]. For convenience of the reader, some of the major definitions are restated here.¶

TODO: find good accurate definitions of these terms & order them¶

UAS RID identifier:

a term used in this document to encompass the use of a DET to be used as any combination of the following: UAS Specific Session ID, Authentication Key ID and Encryption Key ID.¶

DRIP Identity Management Entity (DIME):

Originally defined in [RFC9434] and expanded technically in [DET-DNS]. An entity providing registrar and registry services specifically for DETs.¶

Attestation:

i.e. secure boot of a device¶

Authentication:

of the individual (essential)¶

Authorization:

the admin action of defining roles and what access is permitted for them & the subsequent reference to these roles in policy based determination to grant or deny specific access requests¶

Access Control:

i.e. zero trust. Fine grained near real time access control¶

Attribution:

every action needs to attributable to who took it¶

Accounting:

resource use MUST be tracked¶

Audit:

look back at any of the above after the fact¶

3.1. UAS Observers

An Observer has many motivations for detecting Broadcast RID. Regardless of their motivation the authenticity of the data presented is important for them to make decisions on their next actions. This is accomplished by the use of Authentication of the Broadcast RID, something DRIP provides. Observers also may need additional information, beyond what is sent over Broadcast RID. While the use of a Session ID provides a level of privacy, the use of DRIP allows this privacy while also enabling authorized queries for additional data.¶

An Observer device is expected to be able to process messages compliant with [F3586] and [F3411] Broadcast RID including:¶

1. Basic ID Message (Message Type 0x0), UAS ID Type 0x4 (Specific Session ID), Specific Session ID Type 0x01 (DRIP Entity Tag). The UAS ID SHOULD be displayed either in the style of an IPv6 address per [RFC5952] or as described in Appendix A.¶
2. Authentication Messages (Message Type 0x2), Authentication Type 0x5 (Specific Authentication Method (SAM)), SAM Types 0x01 (DRIP Link), 0x02 (DRIP Wrapper), 0x03 (DRIP Manifest) and optionally 0x04 (DRIP Frame). The details of these SAM Types are described in [RFC9575]. Observer devices MUST follow the requirements of Section 6.4.2 of [RFC9575]. Appendix A of [RFC9575] is RECOMMENDED for visualization of the trustworthiness assessment.¶

3.2. UAS Operators

UAS Operators may want to protect the privacy of their details (such as Operator Location) and their reputation. Reputation can be gained or lost with observation and reports of behavior backed by Authentication. They MAY decide for which UAS RID identifier purposes they will use DETs. This choice may be constrained by the jurisdiction's RID regulations.¶

• Author: move to Definitions: whether to use DRIP for an Authentication Key ID only, Single Use Session ID only, or both. The last of these is the natural approach providing the greatest benefits and thus the primary focus of this document.¶

3.3. UAS Manufacturers

Manufacturers typically wish to maintain good reputation of their brands and are often driven by market forces. Such forces include requirements and preferences of both UAS Observers and Operators.¶

To satisfy CAA requirements, a UA MUST transmit whatever [F3411] messages are needed to carry at least the minimal elements of information required by the regulator. In the US, under the current FAA RID rule, these are Basic ID, Location/Vector, and System as specified in [F3586]. If the content of these messages is to be trusted, the UA MUST also sign those messages, using the DRIP Wrapper and/or DRIP Manifest methods, as described in [RFC9575].¶

• Author: add reference to US RID rule¶

The UAS MUST provide mechanisms and interfaces to enable DET support for UAS Operator selected purposes. For DRIP this requires at minimum the UAS Operator to be able to select DRIP options and start the process of generating and registering a DET with a selected HDA.¶

3.4. HDA Operators

An HDA Operator must fullfil the requirements of their jurisdiction. They must also satisfy the desires of UAS Operators.¶

The HDA MUST provide, upon successful registration of a DET, the four Broadcast Endorsement objects for use in [RFC9575]. These are:¶

• Broadcast Endorsement: RAA:A on RAA:I¶
• Broadcast Endorsement: RAA:I on HDA:A¶
• Broadcast Endorsement: HDA:A on HDA:I¶
• Broadcast Endorsement: HDA:I on Registrant¶

The HDA must also place certain essential information into the Internet Domain Name System (DNS) and maintain that information as operations are activated, completed, etc. All the information to be placed into the DNS is public as it is either needed to make the DET based systems work or because it is a high-availability replica of information transmitted in clear-text via Broadcast RID. The DNS records also MUST point to the private registry in which additional information, required by the HDA/USS itself or the CAA, must be placed and maintained, for query by authorized parties only.¶

3.5. RAA Operators

RAAs in this document are scoped to be operated by a State. Each State is allocated four RAAs, and may decide on their usage.¶

Each RAA MUST register HDAs within its scope. Each RAA MUST provide both widely supported "long form" X.509 certificates and DRIP-specific "short form" endorsements of its HDAs.¶

The RAA MAY provide services to HDAs for verification of data pertaining to UAS Operators. For example an HDA registering a UAS Session ID may query the RAA to verify a previously RAA-registered UAS Serial Number.¶

The RAA Operator MUST obtain valid DNS delegation. See Section 7 for more details.¶

5.1. Query

A DIME has two query interfaces it MUST support. One interface is used for public information query and another (identified and using data found via public queries) is for private information.¶

5.2. Registration

There are several registration functions essential to achieving the purposes to which this document is directed. Likewise there are several viable technical approaches to performing these functions. The only approaches fully specified in [DET-REGISTRATION] are the Constrained Application Protocol (CoAP) [RFC7252] and/or Concise Binary Object Representation (CBOR) Web Tokens (CWT) [RFC8392].¶

DRIP does NOT provide protection against incorrect (e.g. fraudulent) data entered during registration or asserted subsequently. DRIP does protect against alteration (intentional or unintentional) of data subsequent to its assertion by the cryptographic signer. The signer might be the proximate sender (e.g. UA transmitting Broadcast RID) or might be an attestor far away and long ago (e.g. root Certificate Authority). It is the duty of the operator of each DIME, or the party on whose behalf the DIME is being operated, to validate the registration data.¶

5.3. Cross Cutting

DIMEs use and provide various methods to protect data as described below under seven categories: Attestation, Authentication, Authorization, Access Control, Attribution, Accounting and Audit. DRIP refers to these categories collectively as AAA. The definitions of the seven categories are provided in Section 2.1.¶

All data, handled under DRIP, MUST be protected by AAA. All private data MUST also be protected by strong encryption where permitted by law. These requirements apply to data at rest and in transit in all phases of the process, i.e. registration and query.¶

Attestation:

MAY be mandated by CAAs for devices (such as UA). Remote ATtestation ProcedureS (RATS) [RFC9334] is RECOMMENDED by DRIP. The specific attestation mechanisms in a given jurisdiction are out of scope for this document.¶

Authentication:

SHOULD be provided by DIMEs for entities participating in Broadcast RID and if provided MUST follow [RFC9575]¶

Authorization:

TODO¶

Access Control:

MUST be enforced by the DIME to access data from Section 5.1.2. The eXtensible Access Control Markup Language (XACML) MUST be used. The policies to be enforced by XACML MUST be provided by the CAA and are out of scope for this document.¶

Attribution:

TODO¶

Accounting:

TODO¶

Audit:

TODO¶

6.1. Registration Interface

A, B pairs: (registrant, HDA), (HDA, RAA)¶

1: Ensure that CoAP endpoints on B can be accessed according to B's policy by A. Ensure that the endpoints conform to the normative requirements of [DET-REGISTRATION] Test that B interface properly handles valid and malformed data. Test that B securely generates proper artifacts and stores them.¶

2: Ensure that the CoAP interactions for (1) properly returns data to A from B. This data MUST include the Broadcast Endorsements, X.509s and any other data elements required.¶

6.2. Public Query Interface

A, B pairs: (UAS Observer, HDA), (UAS Observer, RAA), (HDA, RAA), (RAA, HDA), (HDA, HDA'), (RAA, RAA')¶

1: Ensure that B has a properly configured and publicly accessible Authoritative Name Server for its delegated ip6.arpa domain.¶

2: Ensure that B returns the valid RRTypes defined in [DET-DNS] to A based on an ip6.arpa query via standard DNS methods (i.e. using UDP on port 53). Ensure that the HHIT RRType contains the correct Certificate with an URI.¶

6.3. Private Query Interface

A, B pairs: (UAS Observer, HDA), (UAS Observer, RAA), (HDA, RAA), (RAA, HDA), (HDA, HDA'), (RAA, RAA')¶

1: Ensure that the provide URI from the public query interface points to a valid URI. Ensure that the endpoint on B has proper AAA mechanisms as defined in this document and enforces the proper policy options.¶

2: Ensure that the B endpoint securely returns the data expected according to policy (matrix of authorized, valid request, unauthorized and invalid request) to A.¶

8.1. DETs as a Locator

TODO¶

9.1. DETs as Session ID and Authentication Key ID

The properties of a DET allow it to be used as a Session ID and/or an Authentication Key ID. There may be scenarios in which Session IDs are desired for privacy but Authentication is not; although this may reduce transparency and security, a DET MAY be used exclusively as a Session ID in such. There are scenarios in which Authentication is desired but Session IDs are not (e.g. where a CAA does not allow Session IDs); a DET MAY be used exclusively as an Authentication Key ID in such. In the scenario expected to be most common, both Session IDs and Authentication are desired; the same DET SHOULD be used as both the Session ID and Authentication Key ID in such.¶

9.2. Selective Encryption

The DET, in its capacity as a Session ID, already acts as a query key for various data elements (both public and private). Selective encryption MAY be allowed when using a Session ID to allow authorized parties to obtain decryption as a service (under UTM, from the USS under which the observed UA is flying) or access decryption key material (under UTM or not, from the HDA) via a private lookup. This enables the encryption of selected data elements in Broadcast RID to provide a layer of privacy for operators (e.g. their position) without compromising transparency to entities (e.g.public safety / law enforcement personnel) that need to know.¶

Selective encryption typically requires network connectivity of the Observer to perform the private query to obtain the decryption service or key material. CAAs should consider the expected Observer environment and prohibit encryption wherever and whenever Observers cannot reasonably be expected to have connectivity. For example selective encryption, per CAA regulations, MAY be allowed in dense urban areas but prohibited in rural areas.¶

The issue of Observer network connectivity MAY be mitigated with the use of a shared key, for encryption/decryption, used by multiple Session IDs in a given HDA over a period of time, that is preloaded onto the Observer before connectivity is lost. For example Observers MAY query HDAs for flight volumes in which they are interested to preload their decryption key(s) for the registrations that day.¶