idnits 2.17.1 draft-ietf-drip-rid-11.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 (20 October 2021) is 919 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 1125, but no explicit reference was found in the text == Unused Reference: 'RFC8392' is defined on line 1142, 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: 23 April 2022 AX Enterprize, LLC 7 A. Gurtov 8 Linköping University 9 20 October 2021 11 DRIP Entity Tag (DET) for Unmanned Aircraft System Remote Identification 12 (UAS RID) 13 draft-ietf-drip-rid-11 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 23 April 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 . . . . . 15 82 4.4. Hierarchy in ORCHID Generation . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . 16 86 6. Other UTM uses of HHITs beyond DET . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . . . . . . 21 94 11.2. Collision risks with DETs . . . . . . . . . . . . . . . 21 96 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 97 12.1. Normative References . . . . . . . . . . . . . . . . . . 21 98 12.2. Informative References . . . . . . . . . . . . . . . . . 22 99 Appendix A. EU U-Space RID Privacy Considerations . . . . . . . 25 100 Appendix B. Example HHIT Self Attestation . . . . . . . . . . . 26 101 B.1. HHIT Offline Self Attestation . . . . . . . . . . . . . . 26 102 Appendix C. Calculating Collision Probabilities . . . . . . . . 27 103 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 28 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 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 CTA 2063-A format is not simple. The CTA 614 2063-A format is defined as: 616 Serial Number := MFR Code | Length Code | MFR SN 618 where: 620 MFR Code : 4 character code assigned by ICAO. 622 Length Code : 1 character Hex encoding of MFR SN length (1-F). 624 MFR SN : Alphanumeric code (0-9, A-Z except O and I). 625 Maximum length of 15 characters. 627 There is no place for the HID; there will need to be a mapping 628 service from Manufacturer Code to HID. The HIT Suite ID and ORCHID 629 hash will take 14 characters (see below), leaving 1 character to 630 distinguish encoded DETs from other manufacturer use of CTA 2063-A 631 Serial Numbers. 633 A character in a CTA 2063-A Serial Number "shall include any 634 combination of digits and uppercase letters, except the letters O and 635 I, but may include all digits". This would allow for a Base34 636 encoding of the binary HIT Suite ID and ORCHID hash. Although, 637 programatically, such a conversion is not hard, other technologies 638 (e.g. credit card payment systems) that have used such odd base 639 encoding have had performance challenges. Thus here a Base32 640 encoding will be used by also excluding the letters Z and S (too 641 similar to the digits 2 and 5). 643 The low-order 68 bits (HIT Suite ID | ORCHID hash) of the HHIT SHALL 644 be left-padded with 2 bits of ZERO. This 70 bit number will be 645 encoded into 14 characters using the digit/letters above. The 646 manufacturer MUST use a Length Code of F (15). The first character 647 after the Length Code MUST be 'Z', followed by the 14 characters of 648 the encoded HIT Suite ID and ORCHID hash. 650 Using the sample DET from Section 5 that is for HDA=20 under RAA=10 651 and having the ICAO CTA MFR Code of 8653, the 20 character CTA 2063-A 652 Serial Number would be: 654 8653FZ2T7B8RA85D19LX 656 A mapping service (e.g. DNS) MUST provide a trusted (e.g. via 657 DNSSEC) conversion of the 4 character Manufacturer Code to high-order 658 60 bits (Prefix | HID) of the HHIT. Definition of this mapping 659 service is currently out of scope of this document. 661 It should be noted that this encoding would only be used in the Basic 662 Message. The HHIT DET will still be used in the Authentication 663 Messages. 665 4.3. Remote ID DET as one class of Hierarchical HITs 667 UAS Remote ID DET may be one of a number of uses of HHITs. However, 668 it is out of the scope of the document to elaborate on other uses of 669 HHITs. As such these follow-on uses need to be considered in 670 allocating the RAAs Section 3.3.1 or HHIT prefix assignments 671 Section 10. 673 4.4. Hierarchy in ORCHID Generation 675 ORCHIDS, as defined in [RFC7343], do not cryptographically bind an 676 IPv6 prefix nor the Orchid Generation Algorithm (OGA) ID (the HIT 677 Suite ID) to the hash of the HI. The rational at the time of 678 developing ORCHID was attacks against these fields are DoS attacks 679 against protocols using ORCHIDs and thus up to those protocols to 680 address the issue. 682 HHITs, as defined in Section 3.5, cryptographically bind all content 683 in the ORCHID through the hashing function. A recipient of a DET 684 that has the underlying HI can directly trust and act on all content 685 in the HHIT. This provides a strong, self-attestation for using the 686 hierarchy to find the DET Registry based on the HID. 688 4.5. DRIP Entity Tag (DET) Registry 690 DETs are registered to Hierarchical HIT Domain Authorities (HDAs). A 691 registration process, [drip-registries], ensures DET global 692 uniqueness (ID-4 in [drip-requirements]). It also provides the 693 mechanism to create UAS Public/Private data that are associated with 694 the DET (REG-1 and REG-2 in [drip-requirements]). 696 The two levels of hierarchy within the DET allows for CAAs to have 697 their own Registered Assigning Authority (RAA) for their National Air 698 Space (NAS). Within the RAA, the CAAs can delegate HDAs as needed. 699 There may be other RAAs allowed to operate within a given NAS; this 700 is a policy decision by the CAA. 702 4.6. Remote ID Authentication using DETs 704 The EdDSA25519 Host Identity (HI) [Section 3.4] underlying the DET 705 can be used in an 84-byte self proof attestation as shown in 706 Appendix B to provide proof of Remote ID ownership (GEN-1 in 707 [drip-requirements]). A lookup service like DNS can provide the HI 708 and registration proof (GEN-3 in [drip-requirements]). 710 Similarly the 200-byte offline self-attestation shown in Appendix B.1 711 provides the same proofs without Internet access and with a small 712 cache that contains the HDA's HI/HHIT and HDA meta-data. These self- 713 attestations are carried in the ASTM Authentication Message (Msg Type 714 0x2). 716 Hashes of previously sent ASTM messages can be placed in a signed 717 "Manifest" Authentication Message (GEN-2 in [drip-requirements]). 718 This can be either a standalone Authentication Message, or an 719 enhanced self attestation Authentication Message. Alternatively the 720 ASTM Message Pack (Msg Type 0xF) can provide this feature, but only 721 over Bluetooth 5 or WiFi BEACON or NAN broadcasts. 723 5. DRIP Entity Tags (DET) in DNS 725 There are two approaches for storing and retrieving the DET using 726 DNS. These are: 728 * As FQDNs in the .aero TLD. 730 * Reverse DNS lookups as IPv6 addresses per [RFC8005]. 732 A DET can be used to construct an FQDN that points to the USS that 733 has the Public/Private information for the UA (REG-1 and REG-2 in 734 [drip-requirements]). For example, the USS for the HHIT could be 735 found via the following: Assume the RAA is 100 and the HDA is 50. 736 The PTR record is constructed as: 738 100.50.det.uas.aero IN PTR foo.uss.aero. 740 The individual DETs are potentially too numerous (e.g. 60 - 600M) and 741 dynamic (new DETs every minute for some HDAs) to actually store in a 742 signed, DNS zone. The HDA SHOULD provide DNS service for its zone 743 and provide the HHIT detail response. A secure connection (e.g. DNS 744 over TLS) to the authoritative zone may be a viable alternative to 745 DNSSEC. 747 The DET reverse lookup can be a standard IPv6 reverse look up, or it 748 can leverage off the HHIT structure. Assume a prefix of 749 2001:30::/28, the RAA is 10 and the HDA is 20 and the DET is: 751 2001:30:a0:145:a3ad:1952:ad0:a69e 753 A DET reverse lookup could be to: 755 a69e.ad0.1952.a3ad.145.a0.30.2001.20.10.det.arpa. 757 A 'standard' ip6.arpa RR has the advantage of only one Registry 758 service supported. 760 $ORIGIN 5.4.1.0.0.a.0.0.0.3.0.0.1.0.0.2.ip6.arpa. 761 e.9.6.a.0.d.a.0.2.5.9.1.d.a.3.a IN PTR 763 6. Other UTM uses of HHITs beyond DET 765 HHITs might be used within the UTM architecture beyond DET (and USS 766 in UA ID registration and authentication). This includes a GCS HHIT 767 ID. The GCS may use its HIIT if it is the source of Network Remote 768 ID for securing the transport and for secure C2 transport (e.g. 769 [drip-secure-nrid-c2]). 771 Observers may have their own HHITs to facilitate UAS information 772 retrieval (e.g., for authorization to private UAS data). They could 773 also use their HHIT for establishing a HIP connection with the UA 774 Pilot for direct communications per authorization (this use is 775 currently outside the scope). Further, they can be used by FINDER 776 observers, (e.g. [crowd-sourced-rid]). 778 7. DRIP Requirements addressed 780 This document in the previous sections provides the details to 781 solutions for GEN 1 - 3, ID 1 - 5, and REG 1 - 2 as describled in 782 [drip-requirements]. 784 8. DET Privacy 786 There is no expectation of privacy for DETs; it is not part of the 787 Privacy Normative Requirements, Section 4.3.1, of 788 [drip-requirements]. DETs are broadcast in the clear over the open 789 air via Bluetooth and WiFi. They will be collected and collated with 790 other public information about the UAS. This will include DET 791 registration information and location and times of operations for a 792 DET. A DET can be for the life of a UA if there is no concern about 793 DET/UA activity harvesting. 795 Further, the MAC address of the wireless interface used for Remote ID 796 broadcasts are a target for UA operation aggregation that may not be 797 mitigated through address randomization. For Bluetooth 4 Remote ID 798 messaging, the MAC address is used by observers to link the Basic 799 Message that contains the RID with other Remote ID messages, thus 800 must be constant for a UA operation. This message linkage use of MAC 801 addresses may not be needed with the Bluetooth 5 or WiFi PHYs. These 802 PHYs provide for a larger message payload and can use the Message 803 Pack (Msg Type 0xF) and the Authentication Message to transmit the 804 RID with other Remote ID messages. However it is not manditory to 805 send the RID in a Message Pack or Authentication Message, so 806 allowance for using the MAC address for UA message linking must be 807 maintained. That is, the MAC address should be stable for at least a 808 UA operation. 810 Finally, it is not adequate to simply change the DET and MAC for a UA 811 per operation to defeat historically tracking a UA's activity. 813 Any changes to the UA MAC may have impacts to C2 setup and use. A 814 constant GCS MAC may well defeat any privacy gains in UA MAC and RID 815 changes. UA/GCS binding is complicated with changing MAC addresses; 816 historically UAS design assumed these to be "forever" and made setup 817 a one-time process. Additionally, if IP is used for C2, a changing 818 MAC may mean a changing IP address to further impact the UAS 819 bindings. Finally an encryption wrapper's identifier (such as ESP 820 [RFC4303] SPI) would need to change per operation to insure operation 821 tracking separation. 823 Creating and maintaining UAS operational privacy is a multifaceted 824 problem. Many communication pieces need to be considered to truly 825 create a separation between UA operations. Simply changing the UAS 826 RID only starts the changes that need to be implemented. 828 9. ASTM Considerations 830 ASTM will need to make the following additional value to the "UA ID" 831 in the Basic Message (Msg Type 0x0): 833 Type 4: 834 This document UA ID of DRIP Entity Tags, DET (see Section 4). 836 The DET authors will participate in ASTM to enact this change. 838 10. IANA Considerations 840 This document requests IANA to make the following changes to the IANA 841 "Host Identity Protocol (HIP) Parameters" registry: 843 Host ID: 844 This document defines the new EdDSA Host ID with value TBD1 845 (suggested: 13) (see Section 3.4.1) in the "HI Algorithm" 846 subregistry of the "Host Identity Protocol (HIP) Parameters" 847 registry. 849 EdDSA Curve Label: 850 This document specifies a new algorithm-specific subregistry named 851 "EdDSA Curve Label". The values for this subregistry are defined 852 in Section 3.4.1. 854 HIT Suite ID: 855 This document defines the new HIT Suite of EdDSA/cSHAKE with value 856 TBD2 (suggested: 5) (see Section 3.4.2) in the "HIT Suite ID" 857 subregistry of the "Host Identity Protocol (HIP) Parameters" 858 registry. 860 HIT Suite ID eight-bit encoding: 861 This document defines the first eight-bit encoded HIT Suite IDs as 862 defined in Section 5.2.10 of [RFC7401]. These are the new HDA 863 domain HIT Suites with values TBD3 and TBD4 (suggested: 0x0E and 864 0x0F) (see Section 3.2.1). IANA is requested to expand the "HIT 865 Suite ID" subregistry of the "Host Identity Protocol (HIP) 866 Parameters" registry to show both the four-bit and eight-bit 867 values as shown in Section 5.2.10 of [RFC7401] and add these new 868 values that only have eight bit representations. 870 10.1. New IPv6 prefix needed for HHITs 872 Because HHIT format is not compatible with [RFC7343], IANA is 873 requested to allocated a new 28-bit prefix out of the IANA IPv6 874 Special Purpose Address Block, namely 2001:0000::/23, as per 875 [RFC6890] (suggested: 2001:30::/28). 877 11. Security Considerations 879 The 64-bit hash in HHITs presents a real risk of second pre-image 880 cryptographic hash attack Section 11.2. There are no known (to the 881 authors) studies of hash size to cryptographic hash attacks. A 882 PYTHON script is available to randomly generate 1M HHITs that did not 883 produce a hash collision which is a simpler attack than a first or 884 second pre-image attack. 886 However, with today's computing power, producing 2^64 EdDSA keypairs 887 and then generating the corresponding HHIT is economically feasible. 888 Consider that a *single* bitcoin mining ASIC can do on the order of 889 2^46 sha256 hashes a second or about 2^62 hashes in a single day. 890 The point being, 2^64 is not prohibitive, especially as this can be 891 done in parallel. 893 Now it should be noted that the 2^64 attempts is for stealing a 894 *specific* HHIT. Say there are roughly 1,024 HHITs for which you'd 895 be happy stealing any one of. Then rather trying to satisfy a 64-bit 896 condition on the cSHAKE128 output, you need only satisfy a 54-bit 897 condition (since you have 2^10 more opportunities for success). 899 Thus, although the PROBABILITY of a collision or pre-image attack is 900 low Section 11.2 in a collection of 1,024 HHITs out of a total 901 population of 2^64, it is computationally and economically feasible. 902 Thus the HHIT registration and HHIT/HI registration validation is 903 STRONGLY recommended. 905 The DET Registry services effectively block attempts to "take over" 906 or "hijack" a DET. It does not stop a rogue attempting to 907 impersonate a known DET. This attack can be mitigated by the 908 receiver of the DET using DNS to find the HI for the DET. As such, 909 use of DNSSEC and DNS over TLS by the DET registries is recommended. 911 The 60 bit hash for DETs with 8 bit OGAs have a greater hash attack 912 risk. As such its use should be restricted to testing and to small, 913 well managed UAS/USS. 915 Another mitigation of HHIT hijacking is if the HI owner (UA) supplies 916 an object containing the HHIT and signed by the HI private key of the 917 HDA such as Appendix B.1 as discussed in Section 4.6. 919 The two risks with hierarchical HITs are the use of an invalid HID 920 and forced HIT collisions. The use of a DNS zone (e.g. "det.arpa.") 921 is a strong protection against invalid HIDs. Querying an HDA's RVS 922 for a HIT under the HDA protects against talking to unregistered 923 clients. The Registry service [drip-registries], through its HHIT 924 uniqueness enforcement, provides against forced or accidental HHIT 925 hash collisions. 927 Cryptographically Generated Addresses (CGAs) provide an assurance of 928 uniqueness. This is two-fold. The address (in this case the UAS ID) 929 is a hash of a public key and a Registry hierarchy naming. Collision 930 resistance (more important that it implied second-preimage 931 resistance) makes it statistically challenging to attacks. A 932 registration process ([drip-registries]) within the HDA provides a 933 level of assured uniqueness unattainable without mirroring this 934 approach. 936 The second aspect of assured uniqueness is the digital signing 937 (attestation) process of the DET by the HI private key and the 938 further signing (attestation) of the HI public key by the Registry's 939 key. This completes the ownership process. The observer at this 940 point does not know WHAT owns the DET, but is assured, other than the 941 risk of theft of the HI private key, that this UAS ID is owned by 942 something and is properly registered. 944 11.1. DET Trust 946 The DET in the ASTM Basic Message (Msg Type 0x0, the actual Remote ID 947 message) does not provide any assertion of trust. The best that 948 might be done within this Basic Message is 4 bytes truncated from a 949 HI signing of the HHIT (the UA ID field is 20 bytes and a HHIT is 950 16). This is not trustable; that is, too open to a hash attack. 951 Minimally, it takes 84 bytes, Appendix B, to prove ownership of a DET 952 with a full EdDSA signature. Thus no attempt has been made to add 953 DET trust directly within the very small Basic Message. 955 The ASTM Authentication Message (Msg Type 0x2) as shown in 956 Section 4.6 can provide practical actual ownership proofs. These 957 attestations include timestamps to defend against replay attacks. 958 But in themselves, they do not prove which UA actually sent the 959 message. They could have been sent by a dog running down the street 960 with a Broadcast Remote ID module strapped to its back. 962 Proof of UA transmission comes when the Authentication Message 963 includes proofs for the ASTM Location/Vector Message (Msg Type 0x1) 964 and the observer can see the UA or that information is validated by 965 ground multilateration [crowd-sourced-rid]. Only then does an 966 observer gain full trust in the DET of the UA. 968 DETs obtained via the Network Remote ID path provides a different 969 approach to trust. Here the UAS SHOULD be securely communicating to 970 the USS (see [drip-secure-nrid-c2]), thus asserting DET trust. 972 11.2. Collision risks with DETs 974 The 64 bit hash size does have an increased risk of collisions over 975 the 96 bit hash size used for the other HIT Suites. There is a 0.01% 976 probability of a collision in a population of 66 million. The 977 probability goes up to 1% for a population of 663 million. See 978 Appendix C for the collision probability formula. 980 However, this risk of collision is within a single "Additional 981 Information" value, i.e. a RAA/HDA domain. The UAS/USS registration 982 process should include registering the DET and MUST reject a 983 collision, forcing the UAS to generate a new HI and thus HHIT and 984 reapplying to the DET registration process. 986 12. References 988 12.1. Normative References 990 [F3411-19] ASTM International, "Standard Specification for Remote ID 991 and Tracking", February 2020, 992 . 994 [NIST.FIPS.202] 995 Dworkin, M., "SHA-3 Standard: Permutation-Based Hash and 996 Extendable-Output Functions", National Institute of 997 Standards and Technology report, 998 DOI 10.6028/nist.fips.202, July 2015, 999 . 1001 [NIST.SP.800-185] 1002 Kelsey, J., Change, S., and R. Perlner, "SHA-3 derived 1003 functions: cSHAKE, KMAC, TupleHash and ParallelHash", 1004 National Institute of Standards and Technology report, 1005 DOI 10.6028/nist.sp.800-185, December 2016, 1006 . 1008 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1009 Requirement Levels", BCP 14, RFC 2119, 1010 DOI 10.17487/RFC2119, March 1997, 1011 . 1013 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 1014 "Special-Purpose IP Address Registries", BCP 153, 1015 RFC 6890, DOI 10.17487/RFC6890, April 2013, 1016 . 1018 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 1019 Signature Algorithm (EdDSA)", RFC 8032, 1020 DOI 10.17487/RFC8032, January 2017, 1021 . 1023 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1024 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1025 May 2017, . 1027 12.2. Informative References 1029 [cfrg-comment] 1030 "A CFRG review of draft-ietf-drip-rid", September 2021, 1031 . 1034 [corus] CORUS, "U-space Concept of Operations", September 2019, 1035 . 1037 [crowd-sourced-rid] 1038 Moskowitz, R., Card, S. W., Wiethuechter, A., Zhao, S., 1039 and H. Birkholz, "Crowd Sourced Remote ID", Work in 1040 Progress, Internet-Draft, draft-moskowitz-drip-crowd- 1041 sourced-rid-06, 26 May 2021, 1042 . 1045 [CTA2063A] ANSI/CTA, "Small Unmanned Aerial Systems Serial Numbers", 1046 September 2019, . 1049 [drip-authentication] 1050 Wiethuechter, A., Card, S., and R. Moskowitz, "DRIP 1051 Authentication Formats", Work in Progress, Internet-Draft, 1052 draft-ietf-drip-auth-01, 18 June 2021, 1053 . 1056 [drip-registries] 1057 Wiethuechter, A., Card, S., and R. Moskowitz, "DRIP 1058 Registries", Work in Progress, Internet-Draft, draft- 1059 wiethuechter-drip-registries-00, 22 February 2021, 1060 . 1063 [drip-requirements] 1064 Card, S. W., Wiethuechter, A., Moskowitz, R., and A. 1065 Gurtov, "Drone Remote Identification Protocol (DRIP) 1066 Requirements", Work in Progress, Internet-Draft, draft- 1067 ietf-drip-reqs-18, 8 September 2021, 1068 . 1071 [drip-secure-nrid-c2] 1072 Moskowitz, R., Card, S. W., Wiethuechter, A., and A. 1073 Gurtov, "Secure UAS Network RID and C2 Transport", Work in 1074 Progress, Internet-Draft, draft-moskowitz-drip-secure- 1075 nrid-c2-03, 2 August 2021, 1076 . 1079 [FAA_RID] United States Federal Aviation Administration (FAA), 1080 "Remote Identification of Unmanned Aircraft", 2021, 1081 . 1084 [hhit-gen] "Python script to generate HHITs", September 2021, 1085 . 1088 [Keccak] Bertoni, G., Daemen, J., Peeters, M., Van Assche, G., and 1089 R. Van Keer, "The Keccak Function", 1090 . 1092 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1093 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1094 DOI 10.17487/RFC4122, July 2005, 1095 . 1097 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1098 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1099 . 1101 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1102 Housley, R., and W. Polk, "Internet X.509 Public Key 1103 Infrastructure Certificate and Certificate Revocation List 1104 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1105 . 1107 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1108 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 1109 . 1111 [RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay 1112 Routable Cryptographic Hash Identifiers Version 2 1113 (ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September 1114 2014, . 1116 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 1117 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 1118 RFC 7401, DOI 10.17487/RFC7401, April 2015, 1119 . 1121 [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data 1122 (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March 1123 2015, . 1125 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1126 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1127 . 1129 [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 1130 Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, 1131 October 2016, . 1133 [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name 1134 System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, 1135 October 2016, . 1137 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1138 (IPv6) Specification", STD 86, RFC 8200, 1139 DOI 10.17487/RFC8200, July 2017, 1140 . 1142 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 1143 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 1144 May 2018, . 1146 Appendix A. EU U-Space RID Privacy Considerations 1148 EU is defining a future of airspace management known as U-space 1149 within the Single European Sky ATM Research (SESAR) undertaking. 1150 Concept of Operation for EuRopean UTM Systems (CORUS) project 1151 proposed low-level Concept of Operations [corus] for UAS in EU. It 1152 introduces strong requirements for UAS privacy based on European GDPR 1153 regulations. It suggests that UAs are identified with agnostic IDs, 1154 with no information about UA type, the operators or flight 1155 trajectory. Only authorized persons should be able to query the 1156 details of the flight with a record of access. 1158 Due to the high privacy requirements, a casual observer can only 1159 query U-space if it is aware of a UA seen in a certain area. A 1160 general observer can use a public U-space portal to query UA details 1161 based on the UA transmitted "Remote identification" signal. Direct 1162 remote identification (DRID) is based on a signal transmitted by the 1163 UA directly. Network remote identification (NRID) is only possible 1164 for UAs being tracked by U-Space and is based on the matching the 1165 current UA position to one of the tracks. 1167 The project lists "E-Identification" and "E-Registrations" services 1168 as to be developed. These services can follow the privacy mechanism 1169 proposed in this document. If an "agnostic ID" above refers to a 1170 completely random identifier, it creates a problem with identity 1171 resolution and detection of misuse. On the other hand, a classical 1172 HIT has a flat structure which makes its resolution difficult. The 1173 Hierarchical HITs provide a balanced solution by associating a 1174 registry with the UA identifier. This is not likely to cause a major 1175 conflict with U-space privacy requirements, as the registries are 1176 typically few at a country level (e.g. civil personal, military, law 1177 enforcement, or commercial). 1179 Appendix B. Example HHIT Self Attestation 1181 This section shows example uses of HHIT RID to prove trustworthiness 1182 of the RID and attestation of registration to the RAA|HDA. These are 1183 examples only and other documents will provide fully specified 1184 attestations. Care has been taken in the example design to minimize 1185 the risk of replay attacks. 1187 This ownership/attestation of a HHIT can be proved in 84 bytes via 1188 the following HHIT Self Attestation following [drip-authentication] 1189 format: 1191 * 4 byte Signing Timestamp 1193 * 16 byte HHIT 1195 * 64 byte Signature (EdDSA25519 signature) 1197 The Timestamp MAY be the standard UNIX time at the time of signing. 1198 A protocol specific timestamp may be used to avoid programming 1199 complexities. For example, [F3411-19] uses a 00:00:00 01/01/2019 1200 offset. 1202 To minimize the risk of replay, the UA SHOULD create a new Self 1203 Attestation, with a new timestamp, at least once a minute. The UA 1204 MAY precompute these attestations and transmit during the appropriate 1205 1 minute window. 1 minute is chosen as a balance between attestation 1206 compute time against risk. A shorter window of use lessens the risk 1207 of replay. 1209 The signature is over the 20 byte Timestamp + HHIT. 1211 The receiver of such an attestation would need access to the 1212 underlying public key (HI) to validate the signature. This may be 1213 obtained via a DNS query using the HHIT. A larger (116 bytes) Self 1214 Attestation could include the EdDSA25519 HI. This larger 116 1215 attestation allows for signature validation before HHIT lookup to 1216 prove registration attestation. 1218 B.1. HHIT Offline Self Attestation 1220 Ownership and RAA|HDA registration of a HHIT can be proved in 200 1221 bytes without Internet access and a small cache via the following 1222 HHIT Offline Self Attestation [drip-authentication] format: 1224 * 16 byte UA HHIT 1226 * 32 byte UA EdDSA25519 HI 1227 * 4 byte HDA Signing Expiry Timestamp 1229 * 16 byte HDA HHIT 1231 * 64 byte HDA Signature (EdDSA25519 signature) 1233 * 4 byte UA Signing Timestamp 1235 * 64 byte UA Signature (EdDSA25519 signature) 1237 The Timestamps MAY be the standard UNIX time at the time of signing. 1238 A protocol specific timestamp may be used to avoid programming 1239 complexities. For example, [F3411-19] uses a 00:00:00 01/01/2019 1240 offset. 1242 The HDA signature is over the 68 byte UA HHIT + UA HI + HDA Expiry 1243 Timestamp + HDA HHIT. During the UA Registration process, the UA 1244 would provide a Self Attestation to the HDA. The HDA would construct 1245 its attestation of registry with an Expiry Timestamp, its own HHIT, 1246 and its signature, returning a 132 byte HDA Registry Attestation to 1247 the UA. The UA would use this much the same way as its HHIT only in 1248 the Self Attestation above, creating a 200 byte Offline Self 1249 Attestation. 1251 The receiver of such an attestation would need a cache of RAA ID, HDA 1252 ID, HDA HHIT, and HDA HI (min 80 bytes per RAA/HDA). 1254 Appendix C. Calculating Collision Probabilities 1256 The accepted formula for calculating the probability of a collision 1257 is: 1259 p = 1 - e^{-k^2/(2n)} 1261 P Collision Probability 1262 n Total possible population 1263 k Actual population 1265 The following table provides the approximate population size for a 1266 collision for a given total population. 1268 Deployed Population 1269 Total With Collision Risk of 1270 Population .01% 1% 1272 2^96 4T 42T 1273 2^72 1B 10B 1274 2^68 250M 2.5B 1275 2^64 66M 663M 1276 2^60 16M 160M 1278 Acknowledgments 1280 Dr. Gurtov is an adviser on Cybersecurity to the Swedish Civil 1281 Aviation Administration. 1283 Quynh Dang of NIST gave considerable guidance on using Keccak and the 1284 NIST supporting documents. Joan Deamen of the Keccak team was 1285 especially helpful in many aspects of using Keccak. Nicholas 1286 Gajcowski [cfrg-comment] provided a concise hash pre-image security 1287 assessment via the CFRG list. 1289 Authors' Addresses 1291 Robert Moskowitz 1292 HTT Consulting 1293 Oak Park, MI 48237 1294 United States of America 1296 Email: rgm@labs.htt-consult.com 1298 Stuart W. Card 1299 AX Enterprize, LLC 1300 4947 Commercial Drive 1301 Yorkville, NY 13495 1302 United States of America 1304 Email: stu.card@axenterprize.com 1306 Adam Wiethuechter 1307 AX Enterprize, LLC 1308 4947 Commercial Drive 1309 Yorkville, NY 13495 1310 United States of America 1312 Email: adam.wiethuechter@axenterprize.com 1313 Andrei Gurtov 1314 Linköping University 1315 IDA 1316 SE-58183 Linköping 1317 Sweden 1319 Email: gurtov@acm.org