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 4 July 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 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. The HDA SHOULD provide DNS service for its zone and 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 a Prefix of 2001:30::/28, the RAA is 10 and the HDA is 20 and the HHIT is:¶

    2001:30:a0:145:a3ad:1952:ad0:a69e

An HHIT reverse lookup could be to:¶

    a69e.ad0.1952.a3ad.145.a0.30.2001.20.10.hhit.arpa.

A 'standard' ip6.arpa RR has the advantage of only one Registry service supported.¶

    $ORIGIN  5.4.1.0.0.a.0.0.0.3.0.0.1.0.0.2.ip6.arpa.
    e.9.6.a.0.d.a.0.2.5.9.1.d.a.3.a    IN   PTR

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. The GCS could use its HIIT 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].¶

9. Security Considerations

A 64 bit hash space presents a real risk of second pre-image attacks Section 9.2. The HHIT Registry services effectively block attempts to "take over" a HHIT. It does not stop a rogue attempting to impersonate a known HHIT. This attack can be mitigated by the receiver of the HHIT using DNS to find the HI for the HHIT.¶

Another mitigation of HHIT hijacking is if the HI owner (UA) supplies an object containing the HHIT and signed by the HI private key of the HDA such as Appendix E.1 as shown in Section 3.4.¶

The two risks with hierarchical HITs are the use of an invalid HID and forced HIT collisions. The use of a DNS zone (e.g. "hhit.arpa.") is a strong protection against invalid HIDs. Querying an HDA's RVS for a HIT under the HDA protects against talking to unregistered clients. The Registry service has direct protection against forced or accidental HIT hash collisions.¶

Cryptographically Generated Addresses (CGAs) provide a unique assurance of uniqueness. This is two-fold. The address (in this case the UAS ID) is a hash of a public key and a Registry hierarchy naming. Collision resistance (more important that it implied second-preimage resistance) makes it statistically challenging to attacks. A registration process (TBD) within the HDA provides a level of assured uniqueness unattainable without mirroring this approach.¶

The second aspect of assured uniqueness is the digital signing (attestation) process of the HHIT by the HI private key and the further signing (attestation) of the HI public key by the Registry's key. This completes the ownership process. The observer at this point does not know WHAT owns the HHIT, but is assured, other than the risk of theft of the HI private key, that this UAS ID is owned by something and is properly registered.¶

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¶

The Context ID for the ORCHID hash is:¶

    Context ID :=  0x00B5 A69C 795D F5D5 F008 7F56 843F 2C40

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

    Hash[L](Context ID | Input)

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

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

    Hash[L](Context ID | Input)

    Input      :=  HOST_ID
    L          :=  96
    Context ID :=  0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA

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

    Hash[L](Context ID | Input)

    Input      :=  HOST_ID
    L          :=  96
    Context ID :=  0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA

    Hash[L]    :=  The L bit output from the hash function

    Prefix | OGA ID | Hash Output

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 Attestation

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

This ownership/attestation of a HHIT can be proved in 84 bytes via the following HHIT Self Attestation following Appendix F.2.1 format:¶

• 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 Attestation, with a new timestamp, at least once a minute. The UA MAY precompute these attestations and transmit during the appropriate 1 minute window. 1 minute is chosen as a balance between attestation 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 an attestation 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 Attestation could include the EdDSA25519 HI. This larger 116 attestation allows for signature validation before HHIT lookup to prove registration attestation.¶

Appendix F. DRIP Proofs

The DRIP Proofs are a set of custom objects to be used in the USS/UTM system. They are created during the enrollment of an Operator and the provisioning of an Aircraft and are tied to the Operator ID and UAS RID.¶

These structures, when chained together, create two distinct roots of trust. One back to the UAS manufacturer, back to the initial production of a given Aircraft. The other back to the authorizing CAA. These chains can also be used by authorized entities to trace an Aircraft through all owners and flights in the Aircraft's lifetime (something of interest to ICAO).¶

The rest of this section will define the formats of proofs in DRIP as forms of certificates and attestations and their common uses.¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|                                                               |
|                          Hierarchical                         |
|                       Host Identity Tag                       |
|                                                               |
+---------------+---------------+---------------+---------------+
|                                                               |
|                                                               |
|                                                               |
|                              Host                             |
|                            Identity                           |
|                                                               |
|                                                               |
|                                                               |
+---------------+---------------+---------------+---------------+
|                     Expiration Timestamp                      |
+---------------+---------------+---------------+---------------+
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                            Signature                          |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
+---------------+---------------+---------------+---------------+

HHIT           The HHIT of the entity, derived from the HI and
               other information.

HI             The HI of the entity. This is the public half of
               an EdDSA25519 asymmetric keypair.

Expiration     A timestamp signaling the expiration of the
Timestamp      attestation.

Signature      Generated using the asymmetric keypair of the entity.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|                                                               |
|                          Hierarchical                         |
|                       Host Identity Tag                       |
|                                                               |
+---------------+---------------+---------------+---------------+
|                     Expiration Timestamp                      |
+---------------+---------------+---------------+---------------+
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                            Signature                          |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
+---------------+---------------+---------------+---------------+

HHIT           The HHIT of the entity, derived from the HI and
               other information.

Expiration     A timestamp signaling the expiration of the
Timestamp      attestation.

Signature      Generated using the asymmetric keypair of the entity.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|           Length Ax           |           Length Ay           |
+---------------+---------------+---------------+---------------+
|                                                               |
.                                                               .
.                          Assertion X                          .
.                                                               .
|                                                               |
+---------------+---------------+---------------+---------------+
|                                                               |
.                                                               .
.                          Assertion Y                          .
.                                                               .
|                                                               |
+---------------+---------------+---------------+---------------+
|                           Timestamp                           |
+---------------+---------------+---------------+---------------+
|                     Expiration Timestamp                      |
+---------------+---------------+---------------+---------------+
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                            Signature                          |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
+---------------+---------------+---------------+---------------+

Length           Length in bytes of Assertion(X). Encoded as an
Ax               unsigned integer.

Length           Length in bytes of Assertion(Y). Encoded as an
Ay               unsigned integer.

Assertion(X)     The attestation/certificate of entity X.

Assertion(Y)     The attestation/certificate of entity Y.

Timestamp        A timestamp signalling the current time at
                 signing of the certificate.

Expiration       A timestamp signaling the expiration of the
Timestamp        attestation.

Signature        Generated using the asymmetric keypair of the
                 entity.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|                                                               |
|                Hierarchical Host Identity Tag                 |
|                         of Entity X                           |
|                                                               |
+---------------+---------------+---------------+---------------+
|                                                               |
.                                                               .
.                              Ayy                              .
.                                                               .
|                                                               |
+---------------+---------------+---------------+---------------+
|                     Expiration Timestamp                      |
+---------------+---------------+---------------+---------------+
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                            Signature                          |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
+---------------+---------------+---------------+---------------+

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|                                                               |
|                 Hierarchical Host Identity Tag                |
|                         of Entity X                           |
|                                                               |
+---------------+---------------+---------------+---------------+
|                                                               |
|                 Hierarchical Host Identity Tag                |
|                         of Entity Y                           |
|                                                               |
+---------------+---------------+---------------+---------------+
|                                                               |
|                                                               |
|                                                               |
|                   Host Identity of Entity Y                   |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
+---------------+---------------+---------------+---------------+
|                     Expiration Timestamp                      |
+---------------+---------------+---------------+---------------+
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                            Signature                          |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
+---------------+---------------+---------------+---------------+

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