idnits 2.17.1 draft-ietf-drip-rid-10.txt: -(8): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 6 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC7401, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC7343, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (14 September 2021) is 955 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'L' is mentioned on line 549, but not defined == Unused Reference: 'RFC7519' is defined on line 1077, but no explicit reference was found in the text == Unused Reference: 'RFC8392' is defined on line 1094, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'F3411-19' ** Downref: Normative reference to an Informational RFC: RFC 8032 -- Obsolete informational reference (is this intentional?): RFC 7484 (Obsoleted by RFC 9224) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DRIP R. Moskowitz 3 Internet-Draft HTT Consulting 4 Updates: 7401, 7343 (if approved) S. Card 5 Intended status: Standards Track A. Wiethuechter 6 Expires: 18 March 2022 AX Enterprize, LLC 7 A. Gurtov 8 Linköping University 9 14 September 2021 11 DRIP Entity Tag (DET) for Unmanned Aircraft System Remote Identification 12 (UAS RID) 13 draft-ietf-drip-rid-10 15 Abstract 17 This document describes the use of Hierarchical Host Identity Tags 18 (HHITs) as self-asserting IPv6 addresses and thereby a trustable 19 identifier for use as the Unmanned Aircraft System Remote 20 Identification and tracking (UAS RID). Within the context of RID, 21 HHITs will be called DRIP Entity Tags (DET). HHITs self-attest to 22 the included explicit hierarchy that provides Registrar discovery for 23 3rd-party identifier attestation. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 18 March 2022. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 4 61 2.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. The Hierarchical Host Identity Tag (HHIT) . . . . . . . . . . 5 64 3.1. HHIT prefix . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.2. HHIT Suite IDs . . . . . . . . . . . . . . . . . . . . . 6 66 3.2.1. 8 bit HIT Suite IDs . . . . . . . . . . . . . . . . . 6 67 3.3. The Hierarchy ID (HID) . . . . . . . . . . . . . . . . . 7 68 3.3.1. The Registered Assigning Authority (RAA) . . . . . . 7 69 3.3.2. The Hierarchical HIT Domain Authority (HDA) . . . . . 7 70 3.4. Edward Digital Signature Algorithm for HITs . . . . . . . 8 71 3.4.1. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 8 72 3.4.2. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 8 73 3.5. ORCHIDs for Hierarchical HITs . . . . . . . . . . . . . . 9 74 3.5.1. Adding additional information to the ORCHID . . . . . 10 75 3.5.2. ORCHID Encoding . . . . . . . . . . . . . . . . . . . 11 76 3.5.3. ORCHID Decoding . . . . . . . . . . . . . . . . . . . 12 77 3.5.4. Decoding ORCHIDs for HITv2 . . . . . . . . . . . . . 12 78 4. Hierarchical HITs as Remote ID DRIP Entity Tags (DET) . . . . 13 79 4.1. Nontransferablity of HHITs . . . . . . . . . . . . . . . 13 80 4.2. Encoding HHITs in CTA 2063-A Serial Numbers . . . . . . . 13 81 4.3. Remote ID DET as one class of Hierarchical HITs . . . . . 14 82 4.4. Hierarchy in ORCHID Generation . . . . . . . . . . . . . 14 83 4.5. DRIP Entity Tag (DET) Registry . . . . . . . . . . . . . 15 84 4.6. Remote ID Authentication using DETs . . . . . . . . . . . 15 85 5. DRIP Entity Tags (DET) in DNS . . . . . . . . . . . . . . . . 15 86 6. Other UTM uses of HHITs beyond DET . . . . . . . . . . . . . 16 87 7. DRIP Requirements addressed . . . . . . . . . . . . . . . . . 17 88 8. DET Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 17 89 9. ASTM Considerations . . . . . . . . . . . . . . . . . . . . . 18 90 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 91 10.1. New IPv6 prefix needed for HHITs . . . . . . . . . . . . 19 92 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 93 11.1. DET Trust . . . . . . . . . . . . . . . . . . . . . . . 20 94 11.2. Collision risks with DETs . . . . . . . . . . . . . . . 20 96 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 97 12.1. Normative References . . . . . . . . . . . . . . . . . . 21 98 12.2. Informative References . . . . . . . . . . . . . . . . . 21 99 Appendix A. EU U-Space RID Privacy Considerations . . . . . . . 24 100 Appendix B. Example HHIT Self Attestation . . . . . . . . . . . 25 101 B.1. HHIT Offline Self Attestation . . . . . . . . . . . . . . 26 102 Appendix C. Calculating Collision Probabilities . . . . . . . . 26 103 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 106 1. Introduction 108 [drip-requirements] describes an Unmanned Aircraft System Remote 109 Identification and tracking (UAS ID) as unique (ID-4), non-spoofable 110 (ID-5), and identify a registry where the ID is listed (ID-2); all 111 within a 20 character identifier (ID-1). 113 This document describes the use of Hierarchical Host Identity Tags 114 (HHITs) (Section 3) as self-asserting IPv6 addresses and thereby a 115 trustable identifier for use as the UAS Remote ID. HHITs include 116 explicit hierarchy to enable DNS HHIT queries (Host ID for 117 authentication, e.g. [drip-authentication]) and for EPP Registrar 118 discovery [RFC7484] for 3rd-party identification attestation (e.g. 119 [drip-authentication]). 121 HHITs as used within the context of UAS will be labeled as DRIP 122 Entity Tags (DET). Throughout this document HHIT and DET will be 123 used appropriately. HHIT will be used when convering the technology, 124 and DET for their context within UAS RID. 126 HITs are statistically unique through the cryptographic hash feature 127 of second-preimage resistance. The cryptographically-bound addition 128 of the Hierarchy and a HHIT registration process [drip-registries] 129 provide complete, global HHIT uniqueness. This is in contrast to 130 using general identifiers (e.g. a Universally Unique IDentifier 131 (UUID) [RFC4122] or device serial number) as the subject in an X.509 132 [RFC5280] certificate. 134 In a multi-CA (multi Certificate Authority) PKI alternative to HHITs, 135 a Remote ID as the Subject (Section 4.1.2.6 of [RFC5280]) can occur 136 in multiple CAs, possibly fraudulently. CAs within the PKI would 137 need to implement an approach to enforce assurance of the uniqueness 138 achieved with HHITs. 140 Hierarchical HITs provide self-attestation of the HHIT registry. A 141 HHIT can only be in a single registry within a registry system (e.g. 142 Extensible Provisioning Protocol (EPP) [RFC5730] and DNS). 144 Hierarchical HITs are valid, though non-routable, IPv6 addresses 145 [RFC8200]. As such, they fit in many ways within various IETF 146 technologies. 148 2. Terms and Definitions 150 2.1. Requirements Terminology 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 154 "OPTIONAL" in this document are to be interpreted as described in BCP 155 14 [RFC2119] [RFC8174] when, and only when, they appear in all 156 capitals, as shown here. 158 2.2. Notations 160 | Signifies concatenation of information - e.g., X | Y is the 161 concatenation of X and Y. 163 Claim(X,Y): 164 Form of a predicate (X is Y, X has property Y, and most 165 importantly X owns Y). 167 Assertion({X...}): 168 A set of one or more claims. This definition is borrowed from 169 JWT/CWT ([RFC7519]/[RFC8392]). 171 Attestation(X,Y): 172 A signed claim. X attests to Y. 174 Certificate(X,Y): 175 A claim or attestation, Y, signed exclusively by a third party, X, 176 and are only over identities. 178 2.3. Definitions 180 This document uses the terms defined in [drip-requirements]. The 181 following new terms are used in the document: 183 cSHAKE (The customizable SHAKE function [NIST.SP.800-185]): 184 Extends the SHAKE [NIST.FIPS.202] scheme to allow users to 185 customize their use of the SHAKE function. 187 HDA (Hierarchical HIT Domain Authority): 188 The 16-bit field that identifies the HHIT Domain Authority under 189 an Registered Assigning Authority (RAA). 191 HHIT 192 Hierarchical Host Identity Tag. A HIT with extra hierarchical 193 information not found in a standard HIT [RFC7401]. 195 HI 196 Host Identity. The public key portion of an asymmetric key pair 197 used in HIP. 199 HID (Hierarchy ID): 200 The 32 bit field providing the HIT Hierarchy ID. 202 HIP (Host Identity Protocol) 203 The origin of HI, HIT, and HHIT, required for DRIP. 205 HIT 206 Host Identity Tag. A 128-bit handle on the HI. HITs are valid 207 IPv6 addresses. 209 Keccak (KECCAK Message Authentication Code): 210 The family of all sponge functions with a KECCAK-f permutation as 211 the underlying function and multi-rate padding as the padding 212 rule. In particular all the functions referenced from 213 [NIST.FIPS.202] and [NIST.SP.800-185]. 215 KMAC (KECCAK Message Authentication Code [NIST.SP.800-185]): 216 A PRF and keyed hash function based on KECCAK. 218 RAA (Registered Assigning Authority): 219 The 16 bit field identifying the business or organization that 220 manages a registry of HDAs. 222 RVS (Rendezvous Server): 223 The HIP Rendezvous Server for enabling mobility, as defined in 224 [RFC8004]. 226 SHAKE (Secure Hash Algorithm KECCAK [NIST.FIPS.202]): 227 A secure hash that allows for an arbitrary output length. 229 XOF (eXtendable-Output Function [NIST.FIPS.202]): 230 A function on bit strings (also called messages) in which the 231 output can be extended to any desired length. 233 3. The Hierarchical Host Identity Tag (HHIT) 235 The Hierarchical HIT (HHIT) is a small but important enhancement over 236 the flat HIT space. By adding two levels of hierarchical 237 administration control, the HHIT provides for device registration/ 238 ownership, thereby enhancing the trust framework for HITs. 240 HHITs represent the HI in only a 64 bit hash and uses the other 32 241 bits to create a hierarchical administration organization for HIT 242 domains. Hierarchical HIT construction is defined in Section 3.5. 243 The input values for the Encoding rules are in Section 3.5.1. 245 A HHIT is built from the following fields: 247 * IANA prefix (max 28 bit) 249 * 32 bit Hierarchy ID (HID) 251 * 4 (or 8) bit HIT Suite ID 253 * ORCHID hash (96 - prefix length - Suite ID length bits, e.g. 64) 254 See Section 3.5 256 The Context ID for the ORCHID hash is: 258 Context ID := 0x00B5 A69C 795D F5D5 F008 7F56 843F 2C40 260 A python script is available for generating HHITs [hhit-gen]. 262 3.1. HHIT prefix 264 A unique IANA IPv6 prefix, no larger than 28 bit, for HHITs is 265 recommended. It clearly separates the flat-space HIT processing from 266 HHIT processing per Section 3.5. 268 Without a unique prefix, the first 4 bits of the RRA would be 269 interpreted as the HIT Suite ID per HIPv2 [RFC7401]. 271 3.2. HHIT Suite IDs 273 The HIT Suite IDs specifies the HI and hash algorithms. Any HIT 274 Suite ID can be used for HHITs. The 8 bit format is supported (only 275 when the first 4 bits are ZERO), but this reduces the ORCHID hash 276 length. 278 3.2.1. 8 bit HIT Suite IDs 280 Support for 8 bit HIT Suite IDs is allowed in Section 5.2.10 of 281 [RFC7401], but not specified in how ORCHIDs are generated with these 282 longer OGAs. Section 3.5 provides the algorithmic flexibility, 283 allowing for HDA custom HIT Suite IDs as follows: 285 HIT Suite Four-bit ID Eight-bit encoding 286 HDA Assigned 1 NA TBD3 (suggested value 0x0E) 287 HDA Assigned 2 NA TBD4 (suggested value 0x0F) 289 This feature may be used for large-scale experimenting with post 290 quantum computing hashes or similar domain specific needs. Note that 291 currently there is no support for domain specific HI algorithms. 293 3.3. The Hierarchy ID (HID) 295 The Hierarchy ID (HID) provides the structure to organize HITs into 296 administrative domains. HIDs are further divided into 2 fields: 298 * 16 bit Registered Assigning Authority (RAA) 300 * 16 bit Hierarchical HIT Domain Authority (HDA) 302 3.3.1. The Registered Assigning Authority (RAA) 304 An RAA is a business or organization that manages a registry of HDAs. 305 For example, the Federal Aviation Authority (FAA) could be an RAA. 307 The RAA is a 16 bit field (65,536 RAAs) assigned by a numbers 308 management organization, perhaps ICANN's IANA service. An RAA must 309 provide a set of services to allocate HDAs to organizations. It must 310 have a public policy on what is necessary to obtain an HDA. The RAA 311 need not maintain any HIP related services. It must maintain a DNS 312 zone minimally for discovering HID RVS servers. 314 As HHITs may be used in many different domains, RAA should be 315 allocated in blocks with consideration on the likely size of a 316 particular usage. Alternatively, different Prefixes can be used to 317 separate different domains of use of HHTs. 319 This DNS zone may be a PTR for its RAA. It may be a zone in a HHIT 320 specific DNS zone. Assume that the RAA is 100. The PTR record could 321 be constructed: 323 100.hhit.arpa IN PTR raa.bar.com. 325 3.3.2. The Hierarchical HIT Domain Authority (HDA) 327 An HDA may be an ISP or any third party that takes on the business to 328 provide RVS and other needed services for HIP enabled devices. 330 The HDA is an 16 bit field (65,536 HDAs per RAA) assigned by an RAA. 331 An HDA should maintain a set of RVS servers that its client HIP- 332 enabled customers use. How this is done and scales to the 333 potentially millions of customers is outside the scope of this 334 document. This service should be discoverable through the DNS zone 335 maintained by the HDA's RAA. 337 An RAA may assign a block of values to an individual organization. 338 This is completely up to the individual RAA's published policy for 339 delegation. 341 3.4. Edward Digital Signature Algorithm for HITs 343 Edwards-Curve Digital Signature Algorithm (EdDSA) [RFC8032] are 344 specified here for use as Host Identities (HIs) per HIPv2 [RFC7401]. 345 Further the HIT_SUITE_LIST is specified as used in [RFC7343]. 347 See Section 3.2 for use of the HIT Suite for this document. 349 3.4.1. HOST_ID 351 The HOST_ID parameter specifies the public key algorithm, and for 352 elliptic curves, a name. The HOST_ID parameter is defined in 353 Section 5.2.19 of [RFC7401]. 355 Algorithm 356 profiles Values 358 EdDSA TBD1 (suggested value 13) [RFC8032] (RECOMMENDED) 360 For hosts that implement EdDSA as the algorithm, the following EdDSA 361 curves are available: 363 Algorithm Curve Values 365 EdDSA RESERVED 0 366 EdDSA EdDSA25519 1 [RFC8032] 367 EdDSA EdDSA25519ph 2 [RFC8032] 368 EdDSA EdDSA448 3 [RFC8032] 369 EdDSA EdDSA448ph 4 [RFC8032] 371 3.4.2. HIT_SUITE_LIST 373 The HIT_SUITE_LIST parameter contains a list of the supported HIT 374 suite IDs of the Responder. Based on the HIT_SUITE_LIST, the 375 Initiator can determine which source HIT Suite IDs are supported by 376 the Responder. The HIT_SUITE_LIST parameter is defined in 377 Section 5.2.10 of [RFC7401]. 379 The following HIT Suite ID is defined, and the relationship between 380 the four-bit ID value used in the OGA ID field and the eight-bit 381 encoding within the HIT_SUITE_LIST ID field is clarified: 383 HIT Suite 4-bit ID 8-bit encoding 384 RESERVED 0 0x00 385 EdDSA/cSHAKE128 TBD2 (suggested value 5) 0x50 (RECOMMENDED) 387 The following table provides more detail on the above HIT Suite 388 combinations. The input for each generation algorithm is the 389 encoding of the HI as defined in this Appendix. 391 The output of cSHAKE128 is variable per the needs of a specific 392 ORCHID construction. It is at most 96 bits long and is directly used 393 in the ORCHID (without truncation). 395 +=======+===========+=========+===========+====================+ 396 | Index | Hash | HMAC | Signature | Description | 397 | | function | | algorithm | | 398 | | | | family | | 399 +=======+===========+=========+===========+====================+ 400 | 5 | cSHAKE128 | KMAC128 | EdDSA | EdDSA HI hashed | 401 | | | | | with cSHAKE128, | 402 | | | | | output is variable | 403 +-------+-----------+---------+-----------+--------------------+ 405 Table 1: HIT Suites 407 3.5. ORCHIDs for Hierarchical HITs 409 This section improves on ORCHIDv2 [RFC7343] with three enhancements: 411 * Optional Info field between the Prefix and OGA ID. 413 * Increased flexibility on the length of each component in the 414 ORCHID construction, provided the resulting ORCHID is 128 bits. 416 * Use of cSHAKE, NIST SP 800-185 [NIST.SP.800-185], for the hashing 417 function. 419 The Keccak [Keccak] based cSHAKE XOF hash function is a variable 420 output length hash function. As such it does not use the truncation 421 operation that other hashes need. The invocation of cSHAKE specifies 422 the desired number of bits in the hash output. Further, cSHAKE has a 423 parameter 'S' as a customization bit string. This parameter will be 424 used for including the ORCHID Context Identifier in a standard 425 fashion. 427 This ORCHID construction includes the fields in the ORCHID in the 428 hash to protect them against substitution attacks. It also provides 429 for inclusion of additional information, in particular the 430 hierarchical bits of the Hierarchical HIT, in the ORCHID generation. 431 This should be viewed as an addendum to ORCHIDv2 [RFC7343], as it can 432 produce ORCHIDv2 output. 434 3.5.1. Adding additional information to the ORCHID 436 ORCHIDv2 [RFC7343] is currently defined as consisting of three 437 components: 439 ORCHID := Prefix | OGA ID | Encode_96( Hash ) 441 where: 443 Prefix : A constant 28-bit-long bitstring value 444 (IANA IPv6 assigned). 446 OGA ID : A 4-bit long identifier for the Hash_function 447 in use within the specific usage context. When 448 used for HIT generation this is the HIT Suite ID. 450 Encode_96( ) : An extraction function in which output is obtained 451 by extracting the middle 96-bit-long bitstring 452 from the argument bitstring. 454 This addendum will be constructed as follows: 456 ORCHID := Prefix (p) | Info (n) | OGA ID (o) | Hash (m) 458 where: 460 Prefix (p) : An IANA IPv6 assigned prefix (max 28-bit-long). 462 Info (n) : n bits of information that define a use of the 463 ORCHID. n can be zero, that is no additional 464 information. 466 OGA ID (o) : A 4 or 8 bit long identifier for the Hash_function 467 in use within the specific usage context. When 468 used for HIT generation this is the HIT Suite ID. 470 Hash (m) : An extraction function in which output is m bits. 472 p + n + o + m = 128 bits 473 With a 28 bit IPv6 Prefix, the remaining 100 bits can be divided in 474 any manner between the additional information, OGA ID, and the hash 475 output. Care must be taken in determining the size of the hash 476 portion, taking into account risks like pre-image attacks. Thus 64 477 bits as used in Hierarchical HITs may be as small as is acceptable. 478 Note that if a 8 bit OGA is used, the hash may be 4 bits shorter. 479 This may result in a greater risk of pre-image attacks and a 480 corresponding greater need to manage HHIT registration and require 481 look up of the HI from a trusted source. 483 3.5.2. ORCHID Encoding 485 This addendum adds a different encoding process to that currently 486 used in ORCHIDv2. The input to the hash function explicitly includes 487 all the header content plus the Context ID. The header content 488 consists of the Prefix, the Additional Information, and OGA ID (HIT 489 Suite ID). Secondly, the length of the resulting hash is set by sum 490 of the length of the ORCHID header fields. For example, a 28 bit 491 Prefix with 32 bits for the HID and 4 bits for the OGA ID leaves 64 492 bits for the hash length. 494 To achieve the variable length output in a consistent manner, the 495 cSHAKE hash is used. For this purpose, cSHAKE128 is appropriate. 496 The the cSHAKE function call for this addendum is: 498 cSHAKE128(Input, L, "", Context ID) 500 Input := Prefix | Additional Information | OGA ID | HOST_ID 501 L := Length in bits of hash portion of ORCHID 503 For full Suite ID support (those that use fixed length hashes like 504 SHA256), the following hashing can be used (Note: this does NOT 505 produce output Identical to ORCHIDv2 for Prefix of /28 and Additional 506 Information of ZERO length): 508 Hash[L](Context ID | Input) 510 Input := Prefix | Additional Information | OGA ID | HOST_ID 511 L := Length in bits of hash portion of ORCHID 513 Hash[L] := An extraction function in which output is obtained 514 by extracting the middle L-bit-long bitstring 515 from the argument bitstring. 517 Hierarchical HIT uses the same context as all other HIPv2 HIT Suites 518 as they are clearly separated by the distinct HIT Suite ID. 520 3.5.2.1. Encoding ORCHIDs for HITv2 522 This section is included to provide backwards compatibility for 523 ORCHIDv2 [RFC7343] as used for HITv2 [RFC7401]. 525 For HITv2s, the Prefix MUST be 2001:20::/28. Info is length ZERO 526 (not included), and OGA ID is length 4. Thus the HI Hash is length 527 96. Further the Prefix and OGA ID are NOT included in the hash 528 calculation. Thus the following ORCHID calculations for fixed output 529 length hashes are used: 531 Hash[L](Context ID | Input) 533 Input := HOST_ID 534 L := 96 535 Context ID := 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA 537 Hash[L] := An extraction function in which output is obtained 538 by extracting the middle L-bit-long bitstring 539 from the argument bitstring. 541 For variable output length hashes use: 543 Hash[L](Context ID | Input) 545 Input := HOST_ID 546 L := 96 547 Context ID := 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA 549 Hash[L] := The L bit output from the hash function 551 Then the ORCHID is constructed as follows: 553 Prefix | OGA ID | Hash Output 555 3.5.3. ORCHID Decoding 557 With this addendum, the decoding of an ORCHID is determined by the 558 Prefix and OGA ID (HIT Suite ID). ORCHIDv2 [RFC7343] decoding is 559 selected when the Prefix is: 2001:20::/28. 561 For Hierarchical HITs, the decoding is determined by the presence of 562 the HHIT Prefix as specified in the HHIT document. 564 3.5.4. Decoding ORCHIDs for HITv2 566 This section is included to provide backwards compatibility for 567 ORCHIDv2 [RFC7343] as used for HITv2 [RFC7401]. 569 HITv2s are identified by a Prefix of 2001:20::/28. The next 4 bits 570 are the OGA ID. is length 4. The remaining 96 bits are the HI Hash. 572 4. Hierarchical HITs as Remote ID DRIP Entity Tags (DET) 574 Hierarchical HITs are a refinement on the Host Identity Tag (HIT) of 575 HIPv2 [RFC7401]. HHITs require a new Overlay Routable Cryptographic 576 Hash Identifier (ORCHID [RFC7343]) mechanism as described in 577 Section 3.5. HHITs for UAS ID (DET) also use the new EdDSA/SHAKE128 578 HIT suite defined in Section 3.4 (GEN-2 in [drip-requirements]). 579 This hierarchy, cryptographically embedded within the HHIT, provides 580 the information for finding the UA's HHIT registry (ID-3 in 581 [drip-requirements]). 583 ASTM Standard Specification for Remote ID and Tracking [F3411-19] 584 specifies three UAS ID types: 586 TYPE-1 A static, manufacturer assigned, hardware serial number per 587 ANSI/CTA-2063-A "Small Unmanned Aerial System Serial Numbers" 588 [CTA2063A]. 590 TYPE-2 A CAA assigned (presumably static) ID. 592 TYPE-3 A UTM system assigned UUID [RFC4122]. These can be dynamic, 593 but do not need to be. 595 For HHITs to be used effectively as UAS IDs, F3411 should add UAS ID 596 type 4 as DET. 598 4.1. Nontransferablity of HHITs 600 A HI and its HHIT SHOULD NOT be transferable between UA or even 601 between replacement electronics (e.g. replacement of damaged 602 controller CPU) for a UA. The private key for the HI SHOULD be held 603 in a cryptographically secure component. 605 4.2. Encoding HHITs in CTA 2063-A Serial Numbers 607 In some cases it is advantageous to encode HHITs as a CTA 2063-A 608 Serial Number [CTA2063A]. For example, the FAA Remote ID Rules 609 [FAA_RID] state that a Remote ID Module (i.e. not integrated with UA 610 controller) must only use "the serial number of the unmanned 611 aircraft"; CTA 2063-A meets this requirement. 613 Encoding a HHIT within the 2063-A format is not simple. There is no 614 place for the HID; there will need to be a mapping service from 615 Manufacturer Code to HID. The HIT Suite ID and ORCHID hash will take 616 14 characters (see below), leaving only 1 character for the 617 Manufacturer's use of other information. 619 A character in a CTA 2063-A Serial Number "shall include any 620 combination of digits and uppercase letters, except the letters O and 621 I, but may include all digits". This would allow for a Base34 622 encoding of the binary HIT Suite ID and ORCHID hash. Although, 623 programatically, such a conversion is not hard, other technologies 624 (e.g. credit card payment systems) that have used such odd base 625 encoding have had performance challenges. Thus here a Base32 626 encoding will be used by also excluding the letters Z and S (too 627 similar to the digits 2 and 5). 629 The low-order 68 bits (HIT Suite ID | ORCHID hash) of the HHIT SHALL 630 be left-padded with 2 bits of ZERO. This 70 bit number will be 631 encoded into 14 characters using the digit/letters above. The 632 Manufacturer MAY use a Length Code of 14 or 15. If 15, the first 633 character after the Length Code is set by the Manufacturer with the 634 low order 14 characters for the encoded HIT Suite ID and ORCHID hash. 636 A mapping service (e.g. DNS) MUST provide a trusted (e.g. via 637 DNSSEC) conversion of the 4 character Manufacturer Code to high-order 638 60 bits (Prefix | HID) of the HHIT. Definition of this mapping 639 service is currently out of scope of this document. 641 4.3. Remote ID DET as one class of Hierarchical HITs 643 UAS Remote ID DET may be one of a number of uses of HHITs. However, 644 it is out of the scope of the document to elaborate on other uses of 645 HHITs. As such these follow-on uses need to be considered in 646 allocating the RAAs Section 3.3.1 or HHIT prefix assignments 647 Section 10. 649 4.4. Hierarchy in ORCHID Generation 651 ORCHIDS, as defined in [RFC7343], do not cryptographically bind an 652 IPv6 prefix nor the Orchid Generation Algorithm (OGA) ID (the HIT 653 Suite ID) to the hash of the HI. The rational at the time of 654 developing ORCHID was attacks against these fields are DoS attacks 655 against protocols using ORCHIDs and thus up to those protocols to 656 address the issue. 658 HHITs, as defined in Section 3.5, cryptographically bind all content 659 in the ORCHID through the hashing function. A recipient of a DET 660 that has the underlying HI can directly trust and act on all content 661 in the HHIT. This provides a strong, self-attestation for using the 662 hierarchy to find the DET Registry based on the HID. 664 4.5. DRIP Entity Tag (DET) Registry 666 DETs are registered to Hierarchical HIT Domain Authorities (HDAs). A 667 registration process, [drip-registries], ensures DET global 668 uniqueness (ID-4 in [drip-requirements]). It also provides the 669 mechanism to create UAS Public/Private data that are associated with 670 the DET (REG-1 and REG-2 in [drip-requirements]). 672 The two levels of hierarchy within the DET allows for CAAs to have 673 their own Registered Assigning Authority (RAA) for their National Air 674 Space (NAS). Within the RAA, the CAAs can delegate HDAs as needed. 675 There may be other RAAs allowed to operate within a given NAS; this 676 is a policy decision by the CAA. 678 4.6. Remote ID Authentication using DETs 680 The EdDSA25519 Host Identity (HI) [Section 3.4] underlying the DET 681 can be used in an 84-byte self proof attestation as shown in 682 Appendix B to provide proof of Remote ID ownership (GEN-1 in 683 [drip-requirements]). A lookup service like DNS can provide the HI 684 and registration proof (GEN-3 in [drip-requirements]). 686 Similarly the 200-byte offline self-attestation shown in Appendix B.1 687 provides the same proofs without Internet access and with a small 688 cache that contains the HDA's HI/HHIT and HDA meta-data. These self- 689 attestations are carried in the ASTM Authentication Message (Msg Type 690 0x2). 692 Hashes of previously sent ASTM messages can be placed in a signed 693 "Manifest" Authentication Message (GEN-2 in [drip-requirements]). 694 This can be either a standalone Authentication Message, or an 695 enhanced self attestation Authentication Message. Alternatively the 696 ASTM Message Pack (Msg Type 0xF) can provide this feature, but only 697 over Bluetooth 5 or WiFi BEACON or NAN broadcasts. 699 5. DRIP Entity Tags (DET) in DNS 701 There are two approaches for storing and retrieving the DET using 702 DNS. These are: 704 * As FQDNs in the .aero TLD. 706 * Reverse DNS lookups as IPv6 addresses per [RFC8005]. 708 A DET can be used to construct an FQDN that points to the USS that 709 has the Public/Private information for the UA (REG-1 and REG-2 in 710 [drip-requirements]). For example, the USS for the HHIT could be 711 found via the following: Assume the RAA is 100 and the HDA is 50. 712 The PTR record is constructed as: 714 100.50.det.uas.aero IN PTR foo.uss.aero. 716 The individual DETs are potentially too numerous (e.g. 60 - 600M) and 717 dynamic (new DETs every minute for some HDAs) to actually store in a 718 signed, DNS zone. The HDA SHOULD provide DNS service for its zone 719 and provide the HHIT detail response. A secure connection (e.g. DNS 720 over TLS) to the authoritative zone may be a viable alternative to 721 DNSSEC. 723 The DET reverse lookup can be a standard IPv6 reverse look up, or it 724 can leverage off the HHIT structure. Assume a prefix of 725 2001:30::/28, the RAA is 10 and the HDA is 20 and the DET is: 727 2001:30:a0:145:a3ad:1952:ad0:a69e 729 A DET reverse lookup could be to: 731 a69e.ad0.1952.a3ad.145.a0.30.2001.20.10.det.arpa. 733 A 'standard' ip6.arpa RR has the advantage of only one Registry 734 service supported. 736 $ORIGIN 5.4.1.0.0.a.0.0.0.3.0.0.1.0.0.2.ip6.arpa. 737 e.9.6.a.0.d.a.0.2.5.9.1.d.a.3.a IN PTR 739 6. Other UTM uses of HHITs beyond DET 741 HHITs might be used within the UTM architecture beyond DET (and USS 742 in UA ID registration and authentication). This includes a GCS HHIT 743 ID. The GCS may use its HIIT if it is the source of Network Remote 744 ID for securing the transport and for secure C2 transport (e.g. 745 [drip-secure-nrid-c2]). 747 Observers may have their own HHITs to facilitate UAS information 748 retrieval (e.g., for authorization to private UAS data). They could 749 also use their HHIT for establishing a HIP connection with the UA 750 Pilot for direct communications per authorization (this use is 751 currently outside the scope). Further, they can be used by FINDER 752 observers, (e.g. [crowd-sourced-rid]). 754 7. DRIP Requirements addressed 756 This document in the previous sections provides the details to 757 solutions for GEN 1 - 3, ID 1 - 5, and REG 1 - 2 as describled in 758 [drip-requirements]. 760 8. DET Privacy 762 There is no expectation of privacy for DETs; it is not part of the 763 Privacy Normative Requirements, Section 4.3.1, of 764 [drip-requirements]. DETs are broadcast in the clear over the open 765 air via Bluetooth and WiFi. They will be collected and collated with 766 other public information about the UAS. This will include DET 767 registration information and location and times of operations for a 768 DET. A DET can be for the life of a UA if there is no concern about 769 DET/UA activity harvesting. 771 Further, the MAC address of the wireless interface used for Remote ID 772 broadcasts are a target for UA operation aggregation that may not be 773 mitigated through address randomization. For Bluetooth 4 Remote ID 774 messaging, the MAC address is used by observers to link the Basic 775 Message that contains the RID with other Remote ID messages, thus 776 must be constant for a UA operation. This message linkage use of MAC 777 addresses may not be needed with the Bluetooth 5 or WiFi PHYs. These 778 PHYs provide for a larger message payload and can use the Message 779 Pack (Msg Type 0xF) and the Authentication Message to transmit the 780 RID with other Remote ID messages. However it is not manditory to 781 send the RID in a Message Pack or Authentication Message, so 782 allowance for using the MAC address for UA message linking must be 783 maintained. That is, the MAC address should be stable for at least a 784 UA operation. 786 Finally, it is not adequate to simply change the DET and MAC for a UA 787 per operation to defeat historically tracking a UA's activity. 789 Any changes to the UA MAC may have impacts to C2 setup and use. A 790 constant GCS MAC may well defeat any privacy gains in UA MAC and RID 791 changes. UA/GCS binding is complicated with changing MAC addresses; 792 historically UAS design assumed these to be "forever" and made setup 793 a one-time process. Additionally, if IP is used for C2, a changing 794 MAC may mean a changing IP address to further impact the UAS 795 bindings. Finally an encryption wrapper's identifier (such as ESP 796 [RFC4303] SPI) would need to change per operation to insure operation 797 tracking separation. 799 Creating and maintaining UAS operational privacy is a multifaceted 800 problem. Many communication pieces need to be considered to truly 801 create a separation between UA operations. Simply changing the UAS 802 RID only starts the changes that need to be implemented. 804 9. ASTM Considerations 806 ASTM will need to make the following additional value to the "UA ID" 807 in the Basic Message (Msg Type 0x0): 809 Type 4: 810 This document UA ID of DRIP Entity Tags, DET (see Section 4). 812 The DET authors will participate in ASTM to enact this change. 814 10. IANA Considerations 816 This document requests IANA to make the following changes to the IANA 817 "Host Identity Protocol (HIP) Parameters" registry: 819 Host ID: 820 This document defines the new EdDSA Host ID with value TBD1 821 (suggested: 13) (see Section 3.4.1) in the "HI Algorithm" 822 subregistry of the "Host Identity Protocol (HIP) Parameters" 823 registry. 825 EdDSA Curve Label: 826 This document specifies a new algorithm-specific subregistry named 827 "EdDSA Curve Label". The values for this subregistry are defined 828 in Section 3.4.1. 830 HIT Suite ID: 831 This document defines the new HIT Suite of EdDSA/cSHAKE with value 832 TBD2 (suggested: 5) (see Section 3.4.2) in the "HIT Suite ID" 833 subregistry of the "Host Identity Protocol (HIP) Parameters" 834 registry. 836 HIT Suite ID eight-bit encoding: 837 This document defines the first eight-bit encoded HIT Suite IDs as 838 defined in Section 5.2.10 of [RFC7401]. These are the new HDA 839 domain HIT Suites with values TBD3 and TBD4 (suggested: 0x0E and 840 0x0F) (see Section 3.2.1). IANA is requested to expand the "HIT 841 Suite ID" subregistry of the "Host Identity Protocol (HIP) 842 Parameters" registry to show both the four-bit and eight-bit 843 values as shown in Section 5.2.10 of [RFC7401] and add these new 844 values that only have eight bit representations. 846 10.1. New IPv6 prefix needed for HHITs 848 Because HHIT format is not compatible with [RFC7343], IANA is 849 requested to allocated a new 28-bit prefix out of the IANA IPv6 850 Special Purpose Address Block, namely 2001:0000::/23, as per 851 [RFC6890] (suggested: 2001:30::/28). 853 11. Security Considerations 855 The 64-bit hash in HHITs presents a real risk of second pre-image 856 cryptographic hash attack Section 11.2. There are no known (to the 857 authors) studies of hash size to cryptographic hash attacks. A 858 PYTHON script is available to randomly generate 1M HHITs that did not 859 produce a hash collision which is a simpler attack than a first or 860 second pre-image attack. 862 The DET Registry services effectively block attempts to "take over" 863 or "hijack" a DET. It does not stop a rogue attempting to 864 impersonate a known DET. This attack can be mitigated by the 865 receiver of the DET using DNS to find the HI for the DET. As such, 866 use of DNSSEC and DNS over TLS by the DET registries is recommended. 868 The 60 bit hash for DETs with 8 bit OGAs may well have hash attack 869 risks. As such its use should be restricted to testing and to small, 870 well managed UAS. 872 Another mitigation of HHIT hijacking is if the HI owner (UA) supplies 873 an object containing the HHIT and signed by the HI private key of the 874 HDA such as Appendix B.1 as discussed in Section 4.6. 876 The two risks with hierarchical HITs are the use of an invalid HID 877 and forced HIT collisions. The use of a DNS zone (e.g. "det.arpa.") 878 is a strong protection against invalid HIDs. Querying an HDA's RVS 879 for a HIT under the HDA protects against talking to unregistered 880 clients. The Registry service [drip-registries], through its HHIT 881 uniqueness enforcement, provides against forced or accidental HHIT 882 hash collisions. 884 Cryptographically Generated Addresses (CGAs) provide an assurance of 885 uniqueness. This is two-fold. The address (in this case the UAS ID) 886 is a hash of a public key and a Registry hierarchy naming. Collision 887 resistance (more important that it implied second-preimage 888 resistance) makes it statistically challenging to attacks. A 889 registration process ([drip-registries]) within the HDA provides a 890 level of assured uniqueness unattainable without mirroring this 891 approach. 893 The second aspect of assured uniqueness is the digital signing 894 (attestation) process of the DET by the HI private key and the 895 further signing (attestation) of the HI public key by the Registry's 896 key. This completes the ownership process. The observer at this 897 point does not know WHAT owns the DET, but is assured, other than the 898 risk of theft of the HI private key, that this UAS ID is owned by 899 something and is properly registered. 901 11.1. DET Trust 903 The DET in the ASTM Basic Message (Msg Type 0x0, the actual Remote ID 904 message) does not provide any assertion of trust. The best that 905 might be done within this Basic Message is 4 bytes truncated from a 906 HI signing of the HHIT (the UA ID field is 20 bytes and a HHIT is 907 16). This is not trustable; that is, too open to a hash attack. 908 Minimally, it takes 84 bytes, Appendix B, to prove ownership of a DET 909 with a full EdDSA signature. Thus no attempt has been made to add 910 DET trust directly within the very small Basic Message. 912 The ASTM Authentication Message (Msg Type 0x2) as shown in 913 Section 4.6 can provide practical actual ownership proofs. These 914 attestations include timestamps to defend against replay attacks. 915 But in themselves, they do not prove which UA actually sent the 916 message. They could have been sent by a dog running down the street 917 with a Broadcast Remote ID module strapped to its back. 919 Proof of UA transmission comes when the Authentication Message 920 includes proofs for the ASTM Location/Vector Message (Msg Type 0x1) 921 and the observer can see the UA or that information is validated by 922 ground multilateration [crowd-sourced-rid]. Only then does an 923 observer gain full trust in the DET of the UA. 925 DETs obtained via the Network Remote ID path provides a different 926 approach to trust. Here the UAS SHOULD be securely communicating to 927 the USS (see [drip-secure-nrid-c2]), thus asserting DET trust. 929 11.2. Collision risks with DETs 931 The 64 bit hash size does have an increased risk of collisions over 932 the 96 bit hash size used for the other HIT Suites. There is a 0.01% 933 probability of a collision in a population of 66 million. The 934 probability goes up to 1% for a population of 663 million. See 935 Appendix C for the collision probability formula. 937 However, this risk of collision is within a single "Additional 938 Information" value, i.e. a RAA/HDA domain. The UAS/USS registration 939 process should include registering the DET and MUST reject a 940 collision, forcing the UAS to generate a new HI and thus HHIT and 941 reapplying to the DET registration process. 943 12. References 945 12.1. Normative References 947 [F3411-19] ASTM International, "Standard Specification for Remote ID 948 and Tracking", February 2020, 949 . 951 [NIST.FIPS.202] 952 Dworkin, M., "SHA-3 Standard: Permutation-Based Hash and 953 Extendable-Output Functions", National Institute of 954 Standards and Technology report, 955 DOI 10.6028/nist.fips.202, July 2015, 956 . 958 [NIST.SP.800-185] 959 Kelsey, J., Change, S., and R. Perlner, "SHA-3 derived 960 functions: cSHAKE, KMAC, TupleHash and ParallelHash", 961 National Institute of Standards and Technology report, 962 DOI 10.6028/nist.sp.800-185, December 2016, 963 . 965 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 966 Requirement Levels", BCP 14, RFC 2119, 967 DOI 10.17487/RFC2119, March 1997, 968 . 970 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 971 "Special-Purpose IP Address Registries", BCP 153, 972 RFC 6890, DOI 10.17487/RFC6890, April 2013, 973 . 975 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 976 Signature Algorithm (EdDSA)", RFC 8032, 977 DOI 10.17487/RFC8032, January 2017, 978 . 980 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 981 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 982 May 2017, . 984 12.2. Informative References 986 [corus] CORUS, "U-space Concept of Operations", September 2019, 987 . 989 [crowd-sourced-rid] 990 Moskowitz, R., Card, S. W., Wiethuechter, A., Zhao, S., 991 and H. Birkholz, "Crowd Sourced Remote ID", Work in 992 Progress, Internet-Draft, draft-moskowitz-drip-crowd- 993 sourced-rid-06, 26 May 2021, 994 . 997 [CTA2063A] ANSI/CTA, "Small Unmanned Aerial Systems Serial Numbers", 998 September 2019, . 1001 [drip-authentication] 1002 Wiethuechter, A., Card, S., and R. Moskowitz, "DRIP 1003 Authentication Formats", Work in Progress, Internet-Draft, 1004 draft-ietf-drip-auth-01, 18 June 2021, 1005 . 1008 [drip-registries] 1009 Wiethuechter, A., Card, S., and R. Moskowitz, "DRIP 1010 Registries", Work in Progress, Internet-Draft, draft- 1011 wiethuechter-drip-registries-00, 22 February 2021, 1012 . 1015 [drip-requirements] 1016 Card, S. W., Wiethuechter, A., Moskowitz, R., and A. 1017 Gurtov, "Drone Remote Identification Protocol (DRIP) 1018 Requirements", Work in Progress, Internet-Draft, draft- 1019 ietf-drip-reqs-17, 7 July 2021, 1020 . 1023 [drip-secure-nrid-c2] 1024 Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov, 1025 "Secure UAS Network RID and C2 Transport", Work in 1026 Progress, Internet-Draft, draft-moskowitz-drip-secure- 1027 nrid-c2-03, 2 August 2021, 1028 . 1031 [FAA_RID] United States Federal Aviation Administration (FAA), 1032 "Remote Identification of Unmanned Aircraft", 2021, 1033 . 1036 [hhit-gen] "Python script to generate HHITs", September 2021, 1037 . 1040 [Keccak] Bertoni, G., Daemen, J., Peeters, M., Van Assche, G., and 1041 R. Van Keer, "The Keccak Function", 1042 . 1044 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1045 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1046 DOI 10.17487/RFC4122, July 2005, 1047 . 1049 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1050 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1051 . 1053 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1054 Housley, R., and W. Polk, "Internet X.509 Public Key 1055 Infrastructure Certificate and Certificate Revocation List 1056 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1057 . 1059 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1060 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 1061 . 1063 [RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay 1064 Routable Cryptographic Hash Identifiers Version 2 1065 (ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September 1066 2014, . 1068 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 1069 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 1070 RFC 7401, DOI 10.17487/RFC7401, April 2015, 1071 . 1073 [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data 1074 (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March 1075 2015, . 1077 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1078 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1079 . 1081 [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 1082 Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, 1083 October 2016, . 1085 [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name 1086 System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, 1087 October 2016, . 1089 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1090 (IPv6) Specification", STD 86, RFC 8200, 1091 DOI 10.17487/RFC8200, July 2017, 1092 . 1094 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 1095 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 1096 May 2018, . 1098 Appendix A. EU U-Space RID Privacy Considerations 1100 EU is defining a future of airspace management known as U-space 1101 within the Single European Sky ATM Research (SESAR) undertaking. 1102 Concept of Operation for EuRopean UTM Systems (CORUS) project 1103 proposed low-level Concept of Operations [corus] for UAS in EU. It 1104 introduces strong requirements for UAS privacy based on European GDPR 1105 regulations. It suggests that UAs are identified with agnostic IDs, 1106 with no information about UA type, the operators or flight 1107 trajectory. Only authorized persons should be able to query the 1108 details of the flight with a record of access. 1110 Due to the high privacy requirements, a casual observer can only 1111 query U-space if it is aware of a UA seen in a certain area. A 1112 general observer can use a public U-space portal to query UA details 1113 based on the UA transmitted "Remote identification" signal. Direct 1114 remote identification (DRID) is based on a signal transmitted by the 1115 UA directly. Network remote identification (NRID) is only possible 1116 for UAs being tracked by U-Space and is based on the matching the 1117 current UA position to one of the tracks. 1119 The project lists "E-Identification" and "E-Registrations" services 1120 as to be developed. These services can follow the privacy mechanism 1121 proposed in this document. If an "agnostic ID" above refers to a 1122 completely random identifier, it creates a problem with identity 1123 resolution and detection of misuse. On the other hand, a classical 1124 HIT has a flat structure which makes its resolution difficult. The 1125 Hierarchical HITs provide a balanced solution by associating a 1126 registry with the UA identifier. This is not likely to cause a major 1127 conflict with U-space privacy requirements, as the registries are 1128 typically few at a country level (e.g. civil personal, military, law 1129 enforcement, or commercial). 1131 Appendix B. Example HHIT Self Attestation 1133 This section shows example uses of HHIT RID to prove trustworthiness 1134 of the RID and attestation of registration to the RAA|HDA. These are 1135 examples only and other documents will provide fully specified 1136 attestations. Care has been taken in the example design to minimize 1137 the risk of replay attacks. 1139 This ownership/attestation of a HHIT can be proved in 84 bytes via 1140 the following HHIT Self Attestation following [drip-authentication] 1141 format: 1143 * 4 byte Signing Timestamp 1145 * 16 byte HHIT 1147 * 64 byte Signature (EdDSA25519 signature) 1149 The Timestamp MAY be the standard UNIX time at the time of signing. 1150 A protocol specific timestamp may be used to avoid programming 1151 complexities. For example, [F3411-19] uses a 00:00:00 01/01/2019 1152 offset. 1154 To minimize the risk of replay, the UA SHOULD create a new Self 1155 Attestation, with a new timestamp, at least once a minute. The UA 1156 MAY precompute these attestations and transmit during the appropriate 1157 1 minute window. 1 minute is chosen as a balance between attestation 1158 compute time against risk. A shorter window of use lessens the risk 1159 of replay. 1161 The signature is over the 20 byte Timestamp + HHIT. 1163 The receiver of such an attestation would need access to the 1164 underlying public key (HI) to validate the signature. This may be 1165 obtained via a DNS query using the HHIT. A larger (116 bytes) Self 1166 Attestation could include the EdDSA25519 HI. This larger 116 1167 attestation allows for signature validation before HHIT lookup to 1168 prove registration attestation. 1170 B.1. HHIT Offline Self Attestation 1172 Ownership and RAA|HDA registration of a HHIT can be proved in 200 1173 bytes without Internet access and a small cache via the following 1174 HHIT Offline Self Attestation [drip-authentication] format: 1176 * 16 byte UA HHIT 1178 * 32 byte UA EdDSA25519 HI 1180 * 4 byte HDA Signing Expiry Timestamp 1182 * 16 byte HDA HHIT 1184 * 64 byte HDA Signature (EdDSA25519 signature) 1186 * 4 byte UA Signing Timestamp 1188 * 64 byte UA Signature (EdDSA25519 signature) 1190 The Timestamps MAY be the standard UNIX time at the time of signing. 1191 A protocol specific timestamp may be used to avoid programming 1192 complexities. For example, [F3411-19] uses a 00:00:00 01/01/2019 1193 offset. 1195 The HDA signature is over the 68 byte UA HHIT + UA HI + HDA Expiry 1196 Timestamp + HDA HHIT. During the UA Registration process, the UA 1197 would provide a Self Attestation to the HDA. The HDA would construct 1198 its attestation of registry with an Expiry Timestamp, its own HHIT, 1199 and its signature, returning a 132 byte HDA Registry Attestation to 1200 the UA. The UA would use this much the same way as its HHIT only in 1201 the Self Attestation above, creating a 200 byte Offline Self 1202 Attestation. 1204 The receiver of such an attestation would need a cache of RAA ID, HDA 1205 ID, HDA HHIT, and HDA HI (min 80 bytes per RAA/HDA). 1207 Appendix C. Calculating Collision Probabilities 1209 The accepted formula for calculating the probability of a collision 1210 is: 1212 p = 1 - e^{-k^2/(2n)} 1214 P Collision Probability 1215 n Total possible population 1216 k Actual population 1218 The following table provides the approximate population size for a 1219 collision for a given total population. 1221 Deployed Population 1222 Total With Collision Risk of 1223 Population .01% 1% 1225 2^96 4T 42T 1226 2^72 1B 10B 1227 2^68 250M 2.5B 1228 2^64 66M 663M 1229 2^60 16M 160M 1231 Acknowledgments 1233 Dr. Gurtov is an adviser on Cybersecurity to the Swedish Civil 1234 Aviation Administration. 1236 Quynh Dang of NIST gave considerable guidance on using Keccak and the 1237 NIST supporting documents. Joan Deamen of the Keccak team was 1238 especially helpful in many aspects of using Keccak. 1240 Authors' Addresses 1242 Robert Moskowitz 1243 HTT Consulting 1244 Oak Park, MI 48237 1245 United States of America 1247 Email: rgm@labs.htt-consult.com 1249 Stuart W. Card 1250 AX Enterprize, LLC 1251 4947 Commercial Drive 1252 Yorkville, NY 13495 1253 United States of America 1255 Email: stu.card@axenterprize.com 1257 Adam Wiethuechter 1258 AX Enterprize, LLC 1259 4947 Commercial Drive 1260 Yorkville, NY 13495 1261 United States of America 1263 Email: adam.wiethuechter@axenterprize.com 1264 Andrei Gurtov 1265 Linköping University 1266 IDA 1267 SE-58183 Linköping 1268 Sweden 1270 Email: gurtov@acm.org