idnits 2.17.1 draft-ietf-drip-rid-04.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 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 (November 1, 2020) is 1265 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: 'Appendix D' is mentioned on line 260, but not defined == Missing Reference: 'L' is mentioned on line 814, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'F3411-19' ** Downref: Normative reference to an Informational RFC: RFC 8032 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 4 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: May 5, 2021 AX Enterprize, LLC 7 A. Gurtov 8 Linköping University 9 November 1, 2020 11 UAS Remote ID 12 draft-ietf-drip-rid-04 14 Abstract 16 This document describes the use of Hierarchical Host Identity Tags 17 (HHITs) as self-asserting IPv6 addresses and thereby a trustable 18 Identifier for use as the UAS Remote ID. HHITs self-attest to the 19 included explicit hierarchy that provides Registrar discovery for 20 3rd-party ID attestation. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 5, 2021. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Nontransferablity of HHITs . . . . . . . . . . . . . . . 3 57 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 59 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Hierarchical HITs as Remote ID . . . . . . . . . . . . . . . 5 62 3.1. Remote ID as one class of Hierarchical HITs . . . . . . . 5 63 3.2. Hierarchy in ORCHID Generation . . . . . . . . . . . . . 5 64 3.3. Hierarchical HIT Registry . . . . . . . . . . . . . . . . 6 65 3.4. Remote ID Authentication using HHITs . . . . . . . . . . 6 66 4. UAS ID HHIT in DNS . . . . . . . . . . . . . . . . . . . . . 6 67 5. Other UTM uses of HHITs . . . . . . . . . . . . . . . . . . . 7 68 6. DRIP Requirements addressed . . . . . . . . . . . . . . . . . 7 69 7. ASTM Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 9.1. Hierarchical HIT Trust . . . . . . . . . . . . . . . . . 9 73 9.2. Collision risks with Hierarchical HITs . . . . . . . . . 10 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 76 10.2. Informative References . . . . . . . . . . . . . . . . . 11 77 Appendix A. EU U-Space RID Privacy Considerations . . . . . . . 12 78 Appendix B. The Hierarchical Host Identity Tag (HHIT) . . . . . 13 79 B.1. HHIT prefix . . . . . . . . . . . . . . . . . . . . . . . 13 80 B.2. HHIT Suite IDs . . . . . . . . . . . . . . . . . . . . . 13 81 B.2.1. 8 bit HIT Suite IDs . . . . . . . . . . . . . . . . . 14 82 B.3. The Hierarchy ID (HID) . . . . . . . . . . . . . . . . . 14 83 B.3.1. The Registered Assigning Authority (RAA) . . . . . . 14 84 B.3.2. The Hierarchical HIT Domain Authority (HDA) . . . . . 15 85 Appendix C. ORCHIDs for Hierarchical HITs . . . . . . . . . . . 15 86 C.1. Adding additional information to the ORCHID . . . . . . . 15 87 C.2. ORCHID Encoding . . . . . . . . . . . . . . . . . . . . . 17 88 C.2.1. Encoding ORCHIDs for HITv2 . . . . . . . . . . . . . 17 89 C.3. ORCHID Decoding . . . . . . . . . . . . . . . . . . . . . 18 90 C.4. Decoding ORCHIDs for HITv2 . . . . . . . . . . . . . . . 18 91 Appendix D. Edward Digital Signature Algorithm for HITs . . . . 18 92 D.1. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 D.2. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . . . 19 94 Appendix E. Example HHIT Self Attestation . . . . . . . . . . . 20 95 E.1. HHIT Offline Self Attestation . . . . . . . . . . . . . . 21 96 Appendix F. Calculating Collision Probabilities . . . . . . . . 21 97 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 100 1. Introduction 102 [drip-requirements] describes a UAS ID as a "unique (ID-4), non- 103 spoofable (ID-5), and identify a registry where the ID is listed (ID- 104 2)"; all within a 20 character Identifier (ID-1). 106 This document describes the use of Hierarchical HITs (HHITs) 107 (Appendix B) as self-asserting IPv6 addresses and thereby a trustable 108 Identifier for use as the UAS Remote ID. HHITs include explicit 109 hierarchy to provide Registrar discovery for 3rd-party ID 110 attestation. 112 HITs are statistically unique through the cryptographic hash feature 113 of second-preimage resistance. The cryptographically-bound addition 114 of the Hierarchy and a HHIT registration process (TBD; e.g. based on 115 Extensible Provisioning Protocol, [RFC5730]) provide complete, global 116 HHIT uniqueness. This is in contrast to general IDs (e.g. a UUID or 117 device serial number) as the subject in an X.509 certificate. 119 In a multi-CA PKI, a subject can occur in multiple CAs, possibly 120 fraudulently. CAs within the PKI would need to implement an approach 121 to enforce assurance of uniqueness. 123 Hierarchical HITs provide self attestation of the HHIT registry. A 124 HHIT can only be in a single registry within a registry system (e.g. 125 EPP and DNS). 127 Hierarchical HITs are valid, though non-routable, IPv6 addresses. As 128 such, they fit in many ways within various IETF technologies. 130 1.1. Nontransferablity of HHITs 132 HIs and its HHITs SHOULD NOT be transferable between UA or even 133 between replacement electronics for a UA. The private key for the HI 134 SHOULD be held in a cryptographically secure component. 136 2. Terms and Definitions 138 2.1. Requirements Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 142 "OPTIONAL" in this document are to be interpreted as described in BCP 143 14 [RFC2119] [RFC8174] when, and only when, they appear in all 144 capitals, as shown here. 146 2.2. Notation 148 | Signifies concatenation of information - e.g., X | Y is the 149 concatenation of X and Y. 151 2.3. Definitions 153 See [drip-requirements] for common DRIP terms. 155 cSHAKE (The customizable SHAKE function): 156 Extends the SHAKE scheme to allow users to customize their use of 157 the function. 159 HDA (Hierarchical HIT Domain Authority): 160 The 16 bit field identifying the HHIT Domain Authority under an 161 RAA. 163 HHIT 164 Hierarchical Host Identity Tag. A HIT with extra hierarchical 165 information not found in a standard HIT. 167 HI 168 Host Identity. The public key portion of an asymmetric keypair 169 used in HIP. 171 HID (Hierarchy ID): 172 The 32 bit field providing the HIT Hierarchy ID. 174 HIP 175 Host Identity Protocol. The origin of HI, HIT, and HHIT, required 176 for DRIP. Optional full use of HIP enables additional DRIP 177 functionality. 179 HIT 180 Host Identity Tag. A 128 bit handle on the HI. HITs are valid 181 IPv6 addresses. 183 Keccak (KECCAK Message Authentication Code): 184 The family of all sponge functions with a KECCAK-f permutation as 185 the underlying function and multi-rate padding as the padding 186 rule. 188 RAA (Registered Assigning Authority): 189 The 16 bit field identifying the business or organization that 190 manages a registry of HDAs. 192 RVS (Rendezvous Server): 193 The HIP Rendezvous Server for enabling mobility, as defined in 194 [RFC8004]. 196 SHAKE (Secure Hash Algorithm KECCAK): 197 A secure hash that allows for an arbitrary output length. 199 XOF (eXtendable-Output Function): 200 A function on bit strings (also called messages) in which the 201 output can be extended to any desired length. 203 3. Hierarchical HITs as Remote ID 205 Hierarchical HITs are a refinement on the Host Identity Tag (HIT) of 206 HIPv2 [RFC7401]. HHITs require a new ORCHID mechanism as described 207 in Appendix C. HHITs for UAS ID also use the new EdDSA/SHAKE128 HIT 208 suite defined in Appendix D (requirements GEN-2). This hierarchy, 209 cryptographically embedded within the HHIT, provides the information 210 for finding the UA's HHIT registry (ID-3). 212 The current ASTM [F3411-19] specifies three UAS ID types: 214 TYPE-1 A static, manufacturer assigned, hardware serial number per 215 ANSI/CTA-2063-A "Small Unmanned Aerial System Serial Numbers" 216 [CTA2063A]. 218 TYPE-2 A CAA assigned (presumably static) ID. 220 TYPE-3 A UTM system assigned UUID [RFC4122], which can but need not 221 be dynamic. 223 For HHITs to be used effectively as UAS IDs, F3411-19 SHOULD add UAS 224 ID type 4 as HHIT. 226 3.1. Remote ID as one class of Hierarchical HITs 228 UAS Remote ID may be one of a number of uses of HHITs. As such these 229 follow-on uses need to be considered in allocating the RAAs 230 Appendix B.3.1 or HHIT prefix assignments Section 8. 232 3.2. Hierarchy in ORCHID Generation 234 ORCHIDS, as defined in [RFC7343], do not cryptographically bind the 235 IPv6 prefix nor the Orchid Generation Algorithm (OGA) ID (the HIT 236 Suite ID) to the hash of the HI. The justification then was attacks 237 against these fields are DoS attacks against protocols using them. 239 HHITs, as defined in Appendix C, cryptographically bind all content 240 in the ORCHID through the hashing function. Thus a recipient of a 241 HHIT that has the underlying HI can directly act on all content in 242 the HHIT. This provides a strong, self attestation for using the 243 hierarchy to find the HHIT Registry. 245 3.3. Hierarchical HIT Registry 247 HHITs are registered to Hierarchical HIT Domain Authorities (HDAs). 248 A registration process (TBD) ensures UAS ID global uniqueness (ID-4). 249 It also provides the mechanism to create UAS Public/Private data 250 associated with the HHIT UAS ID (REG-1 and REG-2). 252 The 2 levels of hierarchy within the HHIT allows for CAAs to have 253 their own Registered Assigning Authority (RAA) for their National Air 254 Space (NAS). Within the RAA, the CAAs can delegate HDAs as needed. 255 There may be other RAAs allowed to operate within a given NAS; this 256 is a policy decision by the CAA. 258 3.4. Remote ID Authentication using HHITs 260 The EdDSA25519 Host Identity (HI) [Appendix D] underlying the HHIT 261 can be used in an 84 byte self proof attestation as shown in 262 Appendix E to provide proof of Remote ID ownership (requirements GEN- 263 1). An Internet lookup service like DNS can provide the HI and 264 registration proof (requirements GEN-3). 266 Similarly the 200 byte offline self attestation shown in Appendix E.1 267 provide the same proofs without Internet access and with a small 268 cache that contains the HDA's HI/HHIT and HDA meta-data. These self 269 attestations are carried in the ASTM Authentication Message (Msg Type 270 0x2). 272 Hashes of previously sent ASTM messages can be placed in a signed 273 "Manifest" Authentication Message (requirements GEN-2). This can be 274 either a standalone Authentication Message, or an enhanced self 275 attestation Authentication Message. Alternatively the ASTM Message 276 Pack (Msg Type 0xF) can provide this feature, but only over Bluetooth 277 5 or WiFi NAN broadcasts. 279 4. UAS ID HHIT in DNS 281 There are 2 approaches for storing and retrieving the HHIT from DNS. 282 These are: 284 * As FQDNs in the .aero TLD. 286 * Reverse DNS lookups as IPv6 addresses per [RFC8005]. 288 The HHIT can be used to construct an FQDN that points to the USS that 289 has the Public/Private information for the UA (REG-1 and REG-2). For 290 example the USS for the HHIT could be found via the following. 291 Assume the RAA is 100 and the HDA is 50. The PTR record is 292 constructed as: 294 100.50.hhit.uas.aero IN PTR foo.uss.aero. 296 The individual HHITs are potentially too numerous (e.g. 60 - 600M) 297 and dynamic to actually store in a signed, DNS zone. The HDA SHOULD 298 provide DNS service for its zone and provide the HHIT detail 299 response. 301 The HHIT reverse lookup can be a standard IPv6 reverse look up, or it 302 can leverage off the HHIT structure. Assume a Prefix of 303 2001:30::/28, the RAA is 10 and the HDA is 20 and the HHIT is: 305 2001:30:a0:145:a3ad:1952:ad0:a69e 307 An HHIT reverse lookup could be to: 309 a69e.ad0.1952.a3ad.145.a0.30.2001.20.10.hhit.arpa. 311 A 'standard' ip6.arpa RR has the advantage of only one Registry 312 service supported. 314 $ORIGIN 5.4.1.0.0.a.0.0.0.3.0.0.1.0.0.2.ip6.arpa. 315 e.9.6.a.0.d.a.0.2.5.9.1.d.a.3.a IN PTR 317 5. Other UTM uses of HHITs 319 HHITs can be used extensively within the UTM architecture beyond UA 320 ID (and USS in UA ID registration and authentication). This includes 321 a GCS HHIT ID. The GCS could use its HIIT if it is the source of 322 Network Remote ID for securing the transport and for secure C2 323 transport [drip-secure-nrid-c2]. 325 Observers SHOULD have HHITs to facilitate UAS information retrieval 326 (e.g., for authorization to private UAS data). They could also use 327 their HHIT for establishing a HIP connection with the UA Pilot for 328 direct communications per authorization. Further, they can be used 329 by FINDER observers, [crowd-sourced-rid]. 331 6. DRIP Requirements addressed 333 This document provides solutions to GEN 1 - 3, ID 1 - 5, and REG 1 - 334 2. 336 7. ASTM Considerations 338 ASTM will need to make the following changes to the "UA ID" in the 339 Basic Message (Msg Type 0x0): 341 Type 4: 342 This document UA ID of Hierarchical HITs (see Section 3). 344 8. IANA Considerations 346 IANA will need to make the following changes to the "Host Identity 347 Protocol (HIP) Parameters" registries: 349 Host ID: 350 This document defines the new EdDSA Host ID (see Appendix D.1). 352 HIT Suite ID: 353 This document defines the new HIT Suite of EdDSA/cSHAKE (see 354 Appendix D.2). 356 HIT Suite ID: 357 This document defines two new HDA domain HIT Suites (see 358 Appendix B.2.1). 360 Because HHIT format is not compatible with [RFC7343], IANA is 361 requested to allocated a new 28-bit prefix out of the IANA IPv6 362 Special Purpose Address Block, namely 2001:0000::/23, as per 363 [RFC6890]. 365 9. Security Considerations 367 A 64 bit hash space presents a real risk of second pre-image attacks 368 Section 9.2. The HHIT Registry services effectively block attempts 369 to "take over" a HHIT. It does not stop a rogue attempting to 370 impersonate a known HHIT. This attack can be mitigated by the 371 receiver of the HHIT using DNS to find the HI for the HHIT. 373 Another mitigation of HHIT hijacking is if the HI owner (UA) supplies 374 an object containing the HHIT and signed by the HI private key of the 375 HDA such as Appendix E.1 as shown in Section 3.4. 377 The two risks with hierarchical HITs are the use of an invalid HID 378 and forced HIT collisions. The use of a DNS zone (e.g. 379 "hhit.arpa.") is a strong protection against invalid HIDs. Querying 380 an HDA's RVS for a HIT under the HDA protects against talking to 381 unregistered clients. The Registry service has direct protection 382 against forced or accidental HIT hash collisions. 384 Cryptographically Generated Addresses (CGAs) provide a unique 385 assurance of uniqueness. This is two-fold. The address (in this 386 case the UAS ID) is a hash of a public key and a Registry hierarchy 387 naming. Collision resistance (more important that it implied second- 388 preimage resistance) makes it statistically challenging to attacks. 389 A registration process (TBD) within the HDA provides a level of 390 assured uniqueness unattainable without mirroring this approach. 392 The second aspect of assured uniqueness is the digital signing 393 (attestation) process of the HHIT by the HI private key and the 394 further signing (attestation) of the HI public key by the Registry's 395 key. This completes the ownership process. The observer at this 396 point does not know WHAT owns the HHIT, but is assured, other than 397 the risk of theft of the HI private key, that this UAS ID is owned by 398 something and is properly registered. 400 9.1. Hierarchical HIT Trust 402 The HHIT UAS RID in the ASTM Basic Message (Msg Type 0x0, the actual 403 Remote ID message) does not provide any assertion of trust. The best 404 that might be done within this Basic Message is 4 bytes truncated 405 from a HI signing of the HHIT (the UA ID field is 20 bytes and a HHIT 406 is 16). This is not trustable. Minimally, it takes 84 bytes, 407 Appendix E, to prove ownership of a HHIT. 409 The ASTM Authentication Messages (Msg Type 0x2) as shown in 410 Section 3.4 can provide practical actual ownership proofs. These 411 attestations include timestamps to defend against replay attacks. 412 But in themselves, they do not prove which UA actually sent the 413 message. They could have been sent by a dog running down the street 414 with a Broadcast Remote ID device strapped to its back. 416 Proof of UA transmission comes when the Authentication Message 417 includes proofs for the ASTM Location/Vector Message (Msg Type 0x1) 418 and the observer can see the UA or that information is validated by 419 ground multilateration [crowd-sourced-rid]. Only then does an 420 observer gain full trust in the HHIT Remote ID. 422 HHIT Remote IDs obtained via the Network Remote ID path provides a 423 different approach to trust. Here the UAS SHOULD be securely 424 communicating to the USS (see [drip-secure-nrid-c2]), thus asserting 425 HHIT RID trust. 427 9.2. Collision risks with Hierarchical HITs 429 The 64 bit hash size does have an increased risk of collisions over 430 the 96 bit hash size used for the other HIT Suites. There is a 0.01% 431 probability of a collision in a population of 66 million. The 432 probability goes up to 1% for a population of 663 million. See 433 Appendix F for the collision probability formula. 435 However, this risk of collision is within a single "Additional 436 Information" value, i.e. a RAA/HDA domain. The UAS/USS registration 437 process should include registering the HHIT and MUST reject a 438 collision, forcing the UAS to generate a new HI and thus HHIT and 439 reapplying to the registration process. 441 10. References 443 10.1. Normative References 445 [F3411-19] ASTM International, "Standard Specification for Remote ID 446 and Tracking", February 2020, 447 . 449 [NIST.SP.800-185] 450 Kelsey, J., Change, S., and R. Perlner, "SHA-3 derived 451 functions: cSHAKE, KMAC, TupleHash and ParallelHash", 452 National Institute of Standards and Technology report, 453 DOI 10.6028/nist.sp.800-185, December 2016, 454 . 456 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 457 Requirement Levels", BCP 14, RFC 2119, 458 DOI 10.17487/RFC2119, March 1997, 459 . 461 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 462 "Special-Purpose IP Address Registries", BCP 153, 463 RFC 6890, DOI 10.17487/RFC6890, April 2013, 464 . 466 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 467 Signature Algorithm (EdDSA)", RFC 8032, 468 DOI 10.17487/RFC8032, January 2017, 469 . 471 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 472 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 473 May 2017, . 475 10.2. Informative References 477 [corus] CORUS, "U-space Concept of Operations", September 2019, 478 . 480 [crowd-sourced-rid] 481 Moskowitz, R., Card, S., Wiethuechter, A., Zhao, S., and 482 H. Birkholz, "Crowd Sourced Remote ID", Work in Progress, 483 Internet-Draft, draft-moskowitz-drip-crowd-sourced-rid-04, 484 May 20, 2020, . 487 [CTA2063A] ANSI, "Small Unmanned Aerial Systems Serial Numbers", 488 September 2019. 490 [drip-requirements] 491 Card, S., Wiethuechter, A., Moskowitz, R., and A. Gurtov, 492 "Drone Remote Identification Protocol (DRIP) 493 Requirements", Work in Progress, Internet-Draft, draft- 494 ietf-drip-reqs-05, October 16, 2020, 495 . 497 [drip-secure-nrid-c2] 498 Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov, 499 "Secure UAS Network RID and C2 Transport", Work in 500 Progress, Internet-Draft, draft-moskowitz-drip-secure- 501 nrid-c2-01, September 27, 2020, 502 . 505 [Keccak] Bertoni, G., Daemen, J., Peeters, M., Van Assche, G., and 506 R. Van Keer, "The Keccak Function", 507 . 509 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 510 Unique IDentifier (UUID) URN Namespace", RFC 4122, 511 DOI 10.17487/RFC4122, July 2005, 512 . 514 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 515 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 516 . 518 [RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay 519 Routable Cryptographic Hash Identifiers Version 2 520 (ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September 521 2014, . 523 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 524 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 525 RFC 7401, DOI 10.17487/RFC7401, April 2015, 526 . 528 [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 529 Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, 530 October 2016, . 532 [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name 533 System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, 534 October 2016, . 536 Appendix A. EU U-Space RID Privacy Considerations 538 EU is defining a future of airspace management known as U-space 539 within the Single European Sky ATM Research (SESAR) undertaking. 540 Concept of Operation for EuRopean UTM Systems (CORUS) project 541 proposed low-level Concept of Operations [corus] for UAS in EU. It 542 introduces strong requirements for UAS privacy based on European GDPR 543 regulations. It suggests that UAs are identified with agnostic IDs, 544 with no information about UA type, the operators or flight 545 trajectory. Only authorized persons should be able to query the 546 details of the flight with a record of access. 548 Due to the high privacy requirements, a casual observer can only 549 query U-space if it is aware of a UA seen in a certain area. A 550 general observer can use a public U-space portal to query UA details 551 based on the UA transmitted "Remote identification" signal. Direct 552 remote identification (DRID) is based on a signal transmitted by the 553 UA directly. Network remote identification (NRID) is only possible 554 for UAs being tracked by U-Space and is based on the matching the 555 current UA position to one of the tracks. 557 The project lists "E-Identification" and "E-Registrations" services 558 as to be developed. These services can follow the privacy mechanism 559 proposed in this document. If an "agnostic ID" above refers to a 560 completely random identifier, it creates a problem with identity 561 resolution and detection of misuse. On the other hand, a classical 562 HIT has a flat structure which makes its resolution difficult. The 563 Hierarchical HITs provide a balanced solution by associating a 564 registry with the UA identifier. This is not likely to cause a major 565 conflict with U-space privacy requirements, as the registries are 566 typically few at a country level (e.g. civil personal, military, law 567 enforcement, or commercial). 569 Appendix B. The Hierarchical Host Identity Tag (HHIT) 571 The Hierarchical HIT (HHIT) is a small but important enhancement over 572 the flat HIT space. By adding two levels of hierarchical 573 administration control, the HHIT provides for device registration/ 574 ownership, thereby enhancing the trust framework for HITs. 576 HHITs represent the HI in only a 64 bit hash and uses the other 32 577 bits to create a hierarchical administration organization for HIT 578 domains. Hierarchical HIT construction is defined in Appendix C. 579 The input values for the Encoding rules are in Appendix C.1. 581 A HHIT is built from the following fields: 583 * IANA prefix (max 28 bit) 585 * 32 bit Hierarchy ID (HID) 587 * 4 (or 8) bit HIT Suite ID 589 * ORCHID hash (96 - prefix length - Suite ID length bits, e.g. 64) 590 See Appendix C 592 The Context ID for the ORCHID hash is: 594 Context ID := 0x00B5 A69C 795D F5D5 F008 7F56 843F 2C40 596 B.1. HHIT prefix 598 A unique IANA IPv6 prefix, no larger than 28 bit, for HHITs is 599 recommended. It clearly separates the flat-space HIT processing from 600 HHIT processing per Appendix C. 602 Without a unique prefix, the first 4 bits of the RRA would be 603 interpreted as the HIT Suite ID per HIPv2 [RFC7401]. 605 B.2. HHIT Suite IDs 607 The HIT Suite IDs specifies the HI and hash algorithms. Any HIT 608 Suite ID can be used for HHITs. The 8 bit format is supported (only 609 when the first 4 bits are ZERO), but this reduces the ORCHID hash 610 length. 612 B.2.1. 8 bit HIT Suite IDs 614 Support for 8 bit HIT Suite IDs is allowed in Sec 5.2.10, [RFC7401], 615 but not specified in how ORCHIDs are generated with these longer 616 OGAs. Appendix C provides the algorithmic flexiblity, allowing for 617 HDA custom HIT Suite IDs as follows: 619 HIT Suite Four-bit ID Eight-bit encoding 620 HDA Assigned 1 NA 0x0E 621 HDA Assigned 2 NA 0x0F 623 This feature may be used for large-scale experimenting with post 624 quantum computing hashes or similar domain specific needs. Note that 625 currently there is no support for domain specific HI algorithms. 627 B.3. The Hierarchy ID (HID) 629 The Hierarchy ID (HID) provides the structure to organize HITs into 630 administrative domains. HIDs are further divided into 2 fields: 632 * 16 bit Registered Assigning Authority (RAA) 634 * 16 bit Hierarchical HIT Domain Authority (HDA) 636 B.3.1. The Registered Assigning Authority (RAA) 638 An RAA is a business or organization that manages a registry of HDAs. 639 For example, the Federal Aviation Authority (FAA) could be an RAA. 641 The RAA is a 16 bit field (65,536 RAAs) assigned by a numbers 642 management organization, perhaps ICANN's IANA service. An RAA must 643 provide a set of services to allocate HDAs to organizations. It must 644 have a public policy on what is necessary to obtain an HDA. The RAA 645 need not maintain any HIP related services. It must maintain a DNS 646 zone minimally for discovering HID RVS servers. 648 As HHITs may be used in many different domains, RAA should be 649 allocated in blocks with consideration on the likely size of a 650 particular usage. Alternatively, different Prefixes can be used to 651 separate different domains of use of HHTs. 653 This DNS zone may be a PTR for its RAA. It may be a zone in a HHIT 654 specific DNS zone. Assume that the RAA is 100. The PTR record could 655 be constructed: 657 100.hhit.arpa IN PTR raa.bar.com. 659 B.3.2. The Hierarchical HIT Domain Authority (HDA) 661 An HDA may be an ISP or any third party that takes on the business to 662 provide RVS and other needed services for HIP enabled devices. 664 The HDA is an 16 bit field (65,536 HDAs per RAA) assigned by an RAA. 665 An HDA should maintain a set of RVS servers that its client HIP- 666 enabled customers use. How this is done and scales to the 667 potentially millions of customers is outside the scope of this 668 document. This service should be discoverable through the DNS zone 669 maintained by the HDA's RAA. 671 An RAA may assign a block of values to an individual organization. 672 This is completely up to the individual RAA's published policy for 673 delegation. 675 Appendix C. ORCHIDs for Hierarchical HITs 677 This section improves on ORCHIDv2 [RFC7343] with three enhancements: 679 * Optional Info field between the Prefix and OGA ID. 681 * Increased flexibility on the length of each component in the 682 ORCHID construction, provided the resulting ORCHID is 128 bits. 684 * Use of cSHAKE, NIST SP 800-185 [NIST.SP.800-185], for the hashing 685 function. 687 The [Keccak] based cSHAKE XOF hash function is a variable output 688 length hash function. As such it does not use the truncation 689 operation that other hashes need. The invocation of cSHAKE specifies 690 the desired number of bits in the hash output. Further, cSHAKE has a 691 parameter 'S' as a customization bit string. This parameter will be 692 used for including the ORCHID Context Identifier in a standard 693 fashion. 695 This ORCHID construction includes the fields in the ORCHID in the 696 hash to protect them against substitution attacks. It also provides 697 for inclusion of additional information, in particular the 698 hierarchical bits of the Hierarchical HIT, in the ORCHID generation. 699 This should be viewed as an addendum to ORCHIDv2 [RFC7343], as it can 700 produce ORCHIDv2 output. 702 C.1. Adding additional information to the ORCHID 704 ORCHIDv2 [RFC7343] is currently defined as consisting of three 705 components: 707 ORCHID := Prefix | OGA ID | Encode_96( Hash ) 709 where: 711 Prefix : A constant 28-bit-long bitstring value 712 (IANA IPv6 assigned). 714 OGA ID : A 4-bit long identifier for the Hash_function 715 in use within the specific usage context. When 716 used for HIT generation this is the HIT Suite ID. 718 Encode_96( ) : An extraction function in which output is obtained 719 by extracting the middle 96-bit-long bitstring 720 from the argument bitstring. 722 This addendum will be constructed as follows: 724 ORCHID := Prefix (p) | Info (n) | OGA ID (o) | Hash (m) 726 where: 728 Prefix (p) : An IANA IPv6 assigned prefix (max 28-bit-long). 730 Info (n) : n bits of information that define a use of the 731 ORCHID. n can be zero, that is no additional 732 information. 734 OGA ID (o) : A 4 or 8 bit long identifier for the Hash_function 735 in use within the specific usage context. When 736 used for HIT generation this is the HIT Suite ID. 738 Hash (m) : An extraction function in which output is m bits. 740 p + n + o + m = 128 bits 742 With a 28 bit IPv6 Prefix, the remaining 100 bits can be divided in 743 any manner between the additional information, OGA ID, and the hash 744 output. Care must be taken in determining the size of the hash 745 portion, taking into account risks like pre-image attacks. Thus 64 746 bits as used in Hierarchical HITs may be as small as is acceptable. 748 C.2. ORCHID Encoding 750 This addendum adds a different encoding process to that currently 751 used in ORCHIDv2. The input to the hash function explicitly includes 752 all the header content plus the Context ID. The header content 753 consists of the Prefix, the Additional Information, and OGA ID (HIT 754 Suite ID). Secondly, the length of the resulting hash is set by sum 755 of the length of the ORCHID header fields. For example, a 28 bit 756 Prefix with 32 bits for the HID and 4 bits for the OGA ID leaves 64 757 bits for the hash length. 759 To achieve the variable length output in a consistent manner, the 760 cSHAKE hash is used. For this purpose, cSHAKE128 is appropriate. 761 The the cSHAKE function call for this addendum is: 763 cSHAKE128(Input, L, "", Context ID) 765 Input := Prefix | Additional Information | OGA ID | HOST_ID 766 L := Length in bits of hash portion of ORCHID 768 For full Suite ID support (those that use fixed length hashes like 769 SHA256), the following hashing can be used (Note: this does NOT 770 produce output Identical to ORCHIDv2 for Prefix of /28 and Additional 771 Information of ZERO length): 773 Hash[L](Context ID | Input) 775 Input := Prefix | Additional Information | OGA ID | HOST_ID 776 L := Length in bits of hash portion of ORCHID 778 Hash[L] := An extraction function in which output is obtained 779 by extracting the middle L-bit-long bitstring 780 from the argument bitstring. 782 Hierarchical HIT uses the same context as all other HIPv2 HIT Suites 783 as they are clearly separated by the distinct HIT Suite ID. 785 C.2.1. Encoding ORCHIDs for HITv2 787 This section is included to provide backwards compatibility for 788 ORCHIDv2 [RFC7343] as used for HITv2 [RFC7401]. 790 For HITv2s, the Prefix MUST be 2001:20::/28. Info is length ZERO 791 (not included), and OGA ID is length 4. Thus the HI Hash is length 792 96. Further the Prefix and OGA ID are NOT included in the hash 793 calculation. Thus the following ORCHID calculations for fixed output 794 length hashes are used: 796 Hash[L](Context ID | Input) 798 Input := HOST_ID 799 L := 96 800 Context ID := 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA 802 Hash[L] := An extraction function in which output is obtained 803 by extracting the middle L-bit-long bitstring 804 from the argument bitstring. 806 For variable output length hashes use: 808 Hash[L](Context ID | Input) 810 Input := HOST_ID 811 L := 96 812 Context ID := 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA 814 Hash[L] := The L bit output from the hash function 816 Then the ORCHID is constructed as follows: 818 Prefix | OGA ID | Hash Output 820 C.3. ORCHID Decoding 822 With this addendum, the decoding of an ORCHID is determined by the 823 Prefix and OGA ID (HIT Suite ID). ORCHIDv2 [RFC7343] decoding is 824 selected when the Prefix is: 2001:20::/28. 826 For Hierarchical HITs, the decoding is determined by the presence of 827 the HHIT Prefix as specified in the HHIT document. 829 C.4. Decoding ORCHIDs for HITv2 831 This section is included to provide backwards compatibility for 832 ORCHIDv2 [RFC7343] as used for HITv2 [RFC7401]. 834 HITv2s are identified by a Prefix of 2001:20::/28. The next 4 bits 835 are the OGA ID. is length 4. The remaining 96 bits are the HI Hash. 837 Appendix D. Edward Digital Signature Algorithm for HITs 839 Edwards-Curve Digital Signature Algorithm (EdDSA) [RFC8032] are 840 specified here for use as Host Identities (HIs) per HIPv2 [RFC7401]. 841 Further the HIT_SUITE_LIST is specified as used in [RFC7343]. 843 See Appendix B.2 for use of the HIT Suite for this document. 845 D.1. HOST_ID 847 The HOST_ID parameter specifies the public key algorithm, and for 848 elliptic curves, a name. The HOST_ID parameter is defined in 849 Section 5.2.19 of [RFC7401]. 851 Algorithm 852 profiles Values 854 EdDSA 13 [RFC8032] (RECOMMENDED) 856 For hosts that implement EdDSA as the algorithm, the following ECC 857 curves are available: 859 Algorithm Curve Values 861 EdDSA RESERVED 0 862 EdDSA EdDSA25519 1 [RFC8032] 863 EdDSA EdDSA25519ph 2 [RFC8032] 864 EdDSA EdDSA448 3 [RFC8032] 865 EdDSA EdDSA448ph 4 [RFC8032] 867 D.2. HIT_SUITE_LIST 869 The HIT_SUITE_LIST parameter contains a list of the supported HIT 870 suite IDs of the Responder. Based on the HIT_SUITE_LIST, the 871 Initiator can determine which source HIT Suite IDs are supported by 872 the Responder. The HIT_SUITE_LIST parameter is defined in 873 Section 5.2.10 of [RFC7401]. 875 The following HIT Suite ID is defined, and the relationship between 876 the four-bit ID value used in the OGA ID field and the eight-bit 877 encoding within the HIT_SUITE_LIST ID field is clarified: 879 HIT Suite Four-bit ID Eight-bit encoding 880 RESERVED 0 0x00 881 EdDSA/cSHAKE128 5 0x50 (RECOMMENDED) 883 The following table provides more detail on the above HIT Suite 884 combinations. The input for each generation algorithm is the 885 encoding of the HI as defined in this Appendix. 887 The output of cSHAKE128 is variable per the needs of a specific 888 ORCHID construction. It is at most 96 bits long and is directly used 889 in the ORCHID (without truncation). 891 +=======+===========+=========+===========+====================+ 892 | Index | Hash | HMAC | Signature | Description | 893 | | function | | algorithm | | 894 | | | | family | | 895 +=======+===========+=========+===========+====================+ 896 | 5 | cSHAKE128 | KMAC128 | EdDSA | EdDSA HI hashed | 897 | | | | | with cSHAKE128, | 898 | | | | | output is variable | 899 +-------+-----------+---------+-----------+--------------------+ 901 Table 1: HIT Suites 903 Appendix E. Example HHIT Self Attestation 905 This section shows example uses of HHIT RID to prove trustworthiness 906 of the RID and attestation of registration to the RAA|HDA. These are 907 examples only and other documents will provide fully specified 908 attestations. Care has been taken in the example design to minimize 909 the risk of replay attacks. 911 This ownership/attestation of a HHIT can be proved in 84 bytes via 912 the following HHIT Self Attestation: 914 * 4 byte Signing Timestamp 916 * 16 byte HHIT 918 * 64 byte Signature (EdDSA25519 signature) 920 The Timestamp MAY be the standard UNIX time at the time of signing. 921 A protocol specific timestamp may be used to avoid programming 922 complexities. For example, [F3411-19] uses a 00:00:00 01/01/2019 923 offset. 925 To minimize the risk of replay, the UA SHOULD create a new Self 926 Attestation, with a new timestamp, at least once a minute. The UA 927 MAY precompute these attestations and transmit during the appropriate 928 1 minute window. 1 minute is chosen as a balance between attestation 929 compute time against risk. A shorter window of use lessens the risk 930 of replay. 932 The signature is over the 20 byte Timestamp + HHIT. 934 The receiver of such an attestation would need access to the 935 underlying public key (HI) to validate the signature. This may be 936 obtained via a DNS query using the HHIT. A larger (116 bytes) Self 937 Attestation could include the EdDSA25519 HI. This larger 116 938 attestation allows for signature validation before HHIT lookup to 939 prove registration attestation. 941 E.1. HHIT Offline Self Attestation 943 Ownership and RAA|HDA registration of a HHIT can be proved in 200 944 bytes without Internet access and a small cache via the following 945 HHIT Offline Self Attestation: 947 * 16 byte UA HHIT 949 * 32 byte UA EdDSA25519 HI 951 * 4 byte HDA Signing Expiry Timestamp 953 * 16 byte HDA HHIT 955 * 64 byte HDA Signature (EdDSA25519 signature) 957 * 4 byte UA Signing Timestamp 959 * 64 byte UA Signature (EdDSA25519 signature) 961 The Timestamps MAY be the standard UNIX time at the time of signing. 962 A protocol specific timestamp may be used to avoid programming 963 complexities. For example, [F3411-19] uses a 00:00:00 01/01/2019 964 offset. 966 The HDA signature is over the 68 byte UA HHIT + UA HI + HDA Expiry 967 Timestamp + HDA HHIT. During the UA Registration process, the UA 968 would provide a Self Attestation to the HDA. The HDA would construct 969 its attestation of registry with an Expiry Timestamp, its own HHIT, 970 and its signature, returning a 132 byte HDA Registry Attestation to 971 the UA. The UA would use this much the same way as its HHIT only in 972 the Self Attestation above, creating a 200 byte Offline Self 973 Attestation. 975 The receiver of such an attestation would need a cache of RAA ID, HDA 976 ID, HDA HHIT, and HDA HI (min 80 bytes per RAA/HDA). 978 Appendix F. Calculating Collision Probabilities 980 The accepted formula for calculating the probability of a collision 981 is: 983 p = 1 - e^{-k^2/(2n)} 985 P Collision Probability 986 n Total possible population 987 k Actual population 989 The following table provides the approximate population size for a 990 collision for a given total population. 992 Deployed Population 993 Total With Collision Risk of 994 Population .01% 1% 996 2^96 4T 42T 997 2^72 1B 10B 998 2^68 250M 2.5B 999 2^64 66M 663M 1000 2^60 16M 160M 1002 Acknowledgments 1004 Dr. Gurtov is an adviser on Cybersecurity to the Swedish Civil 1005 Aviation Administration. 1007 Quynh Dang of NIST gave considerable guidance on using Keccak and the 1008 NIST supporting documents. Joan Deamen of the Keccak team was 1009 especially helpful in many aspects of using Keccak. 1011 Authors' Addresses 1013 Robert Moskowitz 1014 HTT Consulting 1015 Oak Park, MI 48237 1016 United States of America 1018 Email: rgm@labs.htt-consult.com 1020 Stuart W. Card 1021 AX Enterprize, LLC 1022 4947 Commercial Drive 1023 Yorkville, NY 13495 1024 United States of America 1026 Email: stu.card@axenterprize.com 1027 Adam Wiethuechter 1028 AX Enterprize, LLC 1029 4947 Commercial Drive 1030 Yorkville, NY 13495 1031 United States of America 1033 Email: adam.wiethuechter@axenterprize.com 1035 Andrei Gurtov 1036 Linköping University 1037 IDA 1038 SE-58183 Linköping 1039 Sweden 1041 Email: gurtov@acm.org