UAS Remote ID

Status of This Memo

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 March 13, 2021.¶

Copyright Notice

Copyright (c) 2020 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶

Table of Contents

2. Terms and Definitions

3. Hierarchical HITs as Remote ID

Hierarchical HITs are a refinement on the Host Identity Tag (HIT) of HIPv2 [RFC7401]. HHITs require a new ORCHID mechanism as described in Appendix C. HHITs for UAS ID also use the new EdDSA/SHAKE128 HIT suite defined in Appendix D (requirements GEN-2). This hierarchy, cryptographically embedded within the HHIT, provides the information for finding the UA's HHIT registry (ID-3).¶

TYPE-1

A static, manufacturer assigned, hardware serial number per ANSI/CTA-2063-A "Small Unmanned Aerial System Serial Numbers" [CTA2063A].¶

TYPE-2

A CAA assigned (presumably static) ID.¶

TYPE-3

A UTM system assigned UUID [RFC4122], which can but need not be dynamic.¶

For HHITs to be used effectively as UAS IDs, F3411-19 SHOULD add UAS ID type 4 as HHIT.¶

4. UAS ID HHIT in DNS

There are 2 approaches for storing and retrieving the HHIT from DNS. These are:¶

• As FQDNs in the .aero TLD.¶
• Reverse DNS lookups as IPv6 addresses per [RFC8005].¶

The HHIT can be used to construct an FQDN that points to the USS that has the Public/Private information for the UA (REG-1 and REG-2). For example the USS for the HHIT could be found via the following. Assume that the RAA is 100 and the HDA is 50. The PTR record is constructed as:¶

    100.50.hhit.uas.aero   IN PTR      foo.uss.aero.

The individual HHITs are potentially too numerous (e.g. 60 - 600M) and dynamic to actually store in a signed, DNS zone. Rather the USS would provide the HHIT detail response.¶

The HHIT reverse lookup can be a standard IPv6 reverse look up, or it can leverage off the HHIT structure. Assume that the RAA is 10 and the HDA is 20 and the HHIT is:¶

    2001:14:28:14:a3ad:1952:ad0:a69e

An HHIT reverse lookup would be to is:¶

    a69e.ad0.1952.a3ad14.28.14.2001.20.10.hhit.arpa.

5. Other UTM uses of HHITs

HHITs can be used extensively within the UTM architecture beyond UA ID (and USS in UA ID registration and authentication). This includes a GCS HHIT ID. It could use this if it is the source of Network Remote ID for securing the transport and for secure C2 transport [drip-secure-nrid-c2].¶

Observers SHOULD have HHITs to facilitate UAS information retrieval (e.g., for authorization to private UAS data). They could also use their HHIT for establishing a HIP connection with the UA Pilot for direct communications per authorization. Further, they can be used by FINDER observers, [crowd-sourced-rid].¶

6. DRIP Requirements addressed

This document provides solutions to GEN 1 - 3, ID 1 - 5, and REG 1 - 2.¶

7. ASTM Considerations

ASTM will need to make the following changes to the "UA ID" in the Basic Message (Msg Type 0x0):¶

Type 4:

This document UA ID of Hierarchical HITs (see Section 3).¶

8. IANA Considerations

IANA will need to make the following changes to the "Host Identity Protocol (HIP) Parameters" registries:¶

Host ID:

This document defines the new EdDSA Host ID (see Appendix D.1).¶

HIT Suite ID:

This document defines the new HIT Suite of EdDSA/cSHAKE (see Appendix D.2).¶

Because HHIT use of ORCHIDv2 format is not compatible with [RFC7343], IANA is requested to allocated a new 28-bit prefix out of the IANA IPv6 Special Purpose Address Block, namely 2001:0000::/23, as per [RFC6890].¶

Appendix A. EU U-Space RID Privacy Considerations

EU is defining a future of airspace management known as U-space within the Single European Sky ATM Research (SESAR) undertaking. Concept of Operation for EuRopean UTM Systems (CORUS) project proposed low-level Concept of Operations [corus] for UAS in EU. It introduces strong requirements for UAS privacy based on European GDPR regulations. It suggests that UAs are identified with agnostic IDs, with no information about UA type, the operators or flight trajectory. Only authorized persons should be able to query the details of the flight with a record of access.¶

Due to the high privacy requirements, a casual observer can only query U-space if it is aware of a UA seen in a certain area. A general observer can use a public U-space portal to query UA details based on the UA transmitted "Remote identification" signal. Direct remote identification (DRID) is based on a signal transmitted by the UA directly. Network remote identification (NRID) is only possible for UAs being tracked by U-Space and is based on the matching the current UA position to one of the tracks.¶

The project lists "E-Identification" and "E-Registrations" services as to be developed. These services can follow the privacy mechanism proposed in this document. If an "agnostic ID" above refers to a completely random identifier, it creates a problem with identity resolution and detection of misuse. On the other hand, a classical HIT has a flat structure which makes its resolution difficult. The Hierarchical HITs provide a balanced solution by associating a registry with the UA identifier. This is not likely to cause a major conflict with U-space privacy requirements, as the registries are typically few at a country level (e.g. civil personal, military, law enforcement, or commercial).¶

Appendix B. The Hierarchical Host Identity Tag (HHIT)

The Hierarchical HIT (HHIT) is a small but important enhancement over the flat HIT space. By adding two levels of hierarchical administration control, the HHIT provides for device registration/ownership, thereby enhancing the trust framework for HITs.¶

HHITs represent the HI in only a 64 bit hash and uses the other 32 bits to create a hierarchical administration organization for HIT domains. Hierarchical HITs are "Using cSHAKE in ORCHIDs" (Appendix C). The input values for the Encoding rules are in Appendix C.1.¶

A HHIT is built from the following fields:¶

• 28 bit IANA prefix¶
• 4 bit HIT Suite ID¶
• 32 bit Hierarchy ID (HID)¶
• 64 bit ORCHID hash¶

100.hhit.arpa   IN PTR      raa.bar.com.

Appendix C. ORCHIDs for Hierarchical HITs

This section adds the [Keccak] based cSHAKE XOF hash function from NIST SP 800-185 [NIST.SP.800-185] to ORCHIDv2 [RFC7343]. cSHAKE is a variable output length hash function. As such it does not use the truncation operation that other hashes need. The invocation of cSHAKE specifies the desired number of bits in the hash output.¶

This ORCHID construction includes the Prefix in the hash to protect against Prefix subsitution attacks. It also provides for inclusion of additional information, in particular the hierarchical bits of the Hierarchical HIT, in the ORCHID generation. It should be viewed as an addendum to ORCHIDv2 [RFC7343].¶

cSHAKE is used, rather than SHAKE from NIST FIPS 202 [NIST.FIPS.202], as cSHAKE has a parameter 'S' as a customization bit string. This parameter will be used for including the ORCHID Context Identifier in a standard fashion.¶

ORCHID     :=  Prefix | OGA ID | Encode_96( Hash )

where:

Prefix          : A constant 28-bit-long bitstring value
                  (IANA IPv6 assigned).

OGA ID          : A 4-bit long identifier for the Hash_function
                  in use within the specific usage context.  When
                  used for HIT generation this is the HIT Suite ID.

Encode_96( )    : An extraction function in which output is obtained
                  by extracting the middle 96-bit-long bitstring
                  from the argument bitstring.

ORCHID     :=  Prefix | OGA ID | Info (n) | Hash (m)

where:

Prefix (p)      : A (max 28-bit-long) bitstring value
                  (IANA IPv6 assigned).

OGA ID          : A 4-bit long identifier for the Hash_function
                  in use within the specific usage context.  When
                  used for HIT generation this is the HIT Suite ID.

Info (n)        : n bits of information that define a use of the
                  ORCHID.  n can be zero, that is no additional
                  information.

Hash (m)        : An extraction function in which output is m bits.

p + n + m = 124 bits

    cSHAKE128(Input, L, "", Context ID)

    Input      :=  Prefix | OGA ID | Additional Information | HOST_ID
    L          :=  Length in bits of hash portion of ORCHID

Appendix D. Edward Digital Signature Algorithm for HITs

Edwards-Curve Digital Signature Algorithm (EdDSA) [RFC8032] are specified here for use as Host Identities (HIs).¶

     Algorithm
     profiles         Values

     EdDSA            13 [RFC8032]       (RECOMMENDED)

     Algorithm    Curve            Values

     EdDSA        RESERVED         0
     EdDSA        EdDSA25519       1 [RFC8032]
     EdDSA        EdDSA25519ph     2 [RFC8032]
     EdDSA        EdDSA448         3 [RFC8032]
     EdDSA        EdDSA448ph       4 [RFC8032]

     HIT Suite       Four-bit ID    Eight-bit encoding
     RESERVED            0             0x00
     EdDSA/cSHAKE128     5             0x50           (RECOMMENDED)

Appendix E. HHIT Self Claim

Ownership of a HHIT can be proved in 84 bytes via the following HHIT Self Claim:¶

• 4 byte Timestamp¶
• 16 byte HHIT¶
• 64 byte Signature (EdDSA25519 signature)¶

The Timestamp MAY be the standard UNIX time at the time of signing. A protocol specific timestamp may be used to avoid programming complexities. For example, [F3411-19] uses a 00:00:00 01/01/2019 offset.¶

The signature is over the 20 byte Timestamp + HHIT.¶

The receiver of such a claim would need access to the underlying public key (HI) to validate the signature. A larger (116 bytes) self claim could include the EdDSA25519 HI.¶

Appendix F. Calculating Collision Probabilities

The accepted formula for calculating the probability of a collision is:¶

    p = 1 - e^{-k^2/(2n)}


    P   Collision Probability
    n   Total possible population
    k   Actual population

Authors' Addresses