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 27 April 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.a3ad.14.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).¶

HIT Suite ID:

This document defines two new HDA domain HIT Suites (see Appendix B.2.1).¶

Because HHIT 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 HIT construction is defined in Appendix C. The input values for the Encoding rules are in Appendix C.1.¶

A HHIT is built from the following fields:¶

• IANA prefix (max 28 bit)¶
• 32 bit Hierarchy ID (HID)¶
• 4 (or 8) bit HIT Suite ID¶
• ORCHID hash (96 - prefix length - Suite ID length bits, e.g. 64) See Appendix C¶

     HIT Suite       Four-bit ID    Eight-bit encoding
     HDA Assigned 1            NA             0x0E
     HDA Assigned 2            NA             0x0F

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

Appendix C. ORCHIDs for Hierarchical HITs

This section improves on ORCHIDv2 [RFC7343] with three enhancements:¶

• Optional Info field between the Prefix and OGA ID.¶
• Increased flexibility on the length of each component in the ORCHID construction, provided the resulting ORCHID is 128 bits.¶
• Use of cSHAKE, NIST SP 800-185 [NIST.SP.800-185], for the hashing function.¶

The [Keccak] based cSHAKE XOF hash function 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. Further, 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.¶

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

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 (p) | Info (n) | OGA ID (o) | Hash (m)

where:

Prefix (p)      : An IANA IPv6 assigned prefix (max 28-bit-long).

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

OGA ID (o)      : A 4 or 8 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.

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

p + n + o + m = 128 bits

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

    Input      :=  Prefix | Additional Information | OGA ID | HOST_ID
    L          :=  Length in bits of hash portion of ORCHID
    Context ID :=  0x00B5 A69C 795D F5D5 F008 7F56 843F 2C40

    Hash[L](Context ID | Input)

    Input      :=  Prefix | Additional Information | OGA ID | HOST_ID
    L          :=  Length in bits of hash portion of ORCHID
    Context ID :=  0x00B5 A69C 795D F5D5 F008 7F56 843F 2C40

    Hash[L]    :=  An extraction function in which output is obtained
                   by extracting the middle L-bit-long bitstring
                   from the argument bitstring.

Appendix D. Edward Digital Signature Algorithm for HITs

Edwards-Curve Digital Signature Algorithm (EdDSA) [RFC8032] are specified here for use as Host Identities (HIs) per HIPv2 [RFC7401]. Further the HIT_SUITE_LIST is specified as used in [RFC7343].¶

See Appendix B.2 for use of the HIT Suite for this document.¶

     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. Example HHIT Self Claim

This section shows example uses of HHIT RID to prove trustworthiness of the RID. These are examples only and other documents will provide fully specified claims. Care has been taken in the example design to minimize the risk of replay attacks.¶

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

• 4 byte Signing 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.¶

To minimize the risk of replay, the UA SHOULD create a new Self Claim, with a new timestamp, at least once a minute. The UA MAY precompute these claims and transmit during the appropriate 1 minute window. 1 minute is chosen as a balance between claim compute time against risk. A shorter window of use lessens the risk of replay.¶

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. This may be obtained via a DNS query using the HHIT. 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

The following table provides the approximate population size for a collision for a given total population.¶

                       Deployed Population
     Total            With Collision Risk of
     Population         .01%            1%

     2^96                 4T           42T
     2^72                 1B           10B
     2^68               250M          2.5B
     2^64                66M          663M
     2^60                16M          160M

Authors' Addresses