idnits 2.17.1 draft-moskowitz-drip-uas-rid-02.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-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (28 May 2020) is 1421 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DRIP R. Moskowitz 3 Internet-Draft HTT Consulting 4 Intended status: Standards Track S. Card 5 Expires: 29 November 2020 A. Wiethuechter 6 AX Enterprize 7 A. Gurtov 8 Linköping University 9 28 May 2020 11 UAS Remote ID 12 draft-moskowitz-drip-uas-rid-02 14 Abstract 16 This document describes using Hierarchical Host Identity Tags (HHITs) 17 as a self-asserting and thereby trustable Identifier for use as the 18 UAS Remote ID. HHITs include explicit hierarchy to provide Registrar 19 discovery for 3rd-party ID attestation. Further, HHITs can also be 20 used elsewhere in the UTM architecture to facilitate UAS 21 communications. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 29 November 2020. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 59 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Hierarchical HITs as Remote ID . . . . . . . . . . . . . . . 4 61 3.1. Hierarchy in ORCHID generation . . . . . . . . . . . . . 4 62 3.2. Hierarchical HIT Registry . . . . . . . . . . . . . . . . 4 63 3.3. Remote ID Authentication using HHITs . . . . . . . . . . 5 64 4. UAS ID HHIT in DNS . . . . . . . . . . . . . . . . . . . . . 5 65 5. Other UTM uses of HHITs . . . . . . . . . . . . . . . . . . . 6 66 6. DRIP Requirements addressed . . . . . . . . . . . . . . . . . 6 67 7. ASTM Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 70 9.1. Hierarchical HIT Trust . . . . . . . . . . . . . . . . . 7 71 10. Normative References . . . . . . . . . . . . . . . . . . . . 7 72 11. Informative References . . . . . . . . . . . . . . . . . . . 7 73 Appendix A. EU U-Space RID Privacy Considerations . . . . . . . 9 74 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 This document describes the use of Hierarchical HITs (HHITs) 80 [hierarchical-hit] as self-asserting and thereby a trustable 81 Identifier for use as the UAS Remote ID. HHITs include explicit 82 hierarchy to provide Registrar discovery for 3rd-party ID 83 attestation. 85 The Drip Requirements [drip-requirements] describe a UAS ID as a 86 "unique (ID-4), non-spoofable (ID-5), and identify a registry where 87 the ID is listed (ID-2)"; all within a 20 character Identifier (ID- 88 1). 90 HITs are statistically unique through the cryptograhic hash feature 91 of second-preimage resistance. The cryptograhically-bound addition 92 of the Hierarchy and thus HHIT Registries [hhit-registries] provide 93 complete, global HHIT uniqueness. This is in contrast to general IDs 94 (e.g. a UUID or device serial number) as the subject in an X.509 95 certificate. 97 In a multi-CA PKI, a subject can occur in multiple CAs, possibly 98 fraudulently. CAs within the PKI would need to implement an approach 99 to enforce assurance of uniqueness. 101 Hierarchical HITs are valid, though non-routable, IPv6 addresses. As 102 such, they fit in many ways within various IETF technologies. 104 2. Terms and Definitions 106 2.1. Requirements Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in BCP 111 14 [RFC2119] [RFC8174] when, and only when, they appear in all 112 capitals, as shown here. 114 2.2. Definitions 116 See Drip Requirements [drip-requirements] for common DRIP terms. 118 CS-RID 119 Crowd Sourced Remote Identification. An optional DRIP WG service 120 that gateways Broadcast RID to Network RID, and supports 121 verification of RID positon/velocity claims with independent 122 measurements (e.g. by multilateration), via a SDSP. 124 HI 125 Host Identity. The public key portion of an asymmetric keypair 126 used in HIP. 128 HIP 129 Host Identity Protocol. The origin of HI, HIT, and HHIT, required 130 for DRIP. Optional full use of HIP enables additional DRIP 131 functionality. 133 HHIT 134 Hierarchical Host Identity Tag. A HIT with extra hierarchical 135 information not found in a standard HIT. 137 HIT 138 Host Identity Tag. A 128 bit handle on the HI. HITs are valid 139 IPv6 addresses. 141 3. Hierarchical HITs as Remote ID 143 Hierarchical HITs are a refinement on the Host Identity Tag (HIT) of 144 HIPv2 [RFC7401]. HHITs require a new ORCHID mechanism as described 145 in [new-orchid]. HHITs for UAS ID also use the new EdDSA/SHAKE128 146 HIT suite defined in [new-hip-crypto] (requirements GEN-2). This 147 hierarchy, cryptographically embedded within the HHIT, provides the 148 information for finding the UA's HHIT registry (ID-3). 150 The current ASTM [F3411-19] supports three types of UAS IDs, namely 151 the [CTA2063A] serial number, CAA registration ID, and UTM-provided 152 UUID session ID. For HHITs to be used effectively as UAS IDs, 153 F3411-19 SHOULD add HHIT as the fourth UAS ID type. 155 3.1. Hierarchy in ORCHID generation 157 ORCHIDS, as defined in [RFC7343], do not cryptographically bind the 158 IPv6 prefix nor the Orchid Generation Algorithm (OGA) ID to the hash 159 of the HI. The justification then was attacks against these fields 160 are DOS attacks against protocols using them. 162 HHITs, as defined in [new-orchid], cryptographically bind all content 163 in the ORCHID though the hashing function. Thus a recipient of a 164 HHIT that has the underlying HI can directly act on all content in 165 the HHIT. This is especially important to using the hierarchy to 166 find the HHIT Registry. 168 3.2. Hierarchical HIT Registry 170 HHITs are registered to Hierarchical HIT Domain Authorities (HDAs) as 171 described in [hhit-registries]. This registration process ensures 172 UAS ID global uniqueness (ID-4). It also provides the mechanism to 173 create UAS Public/Private data associated with the HHIT UAS ID (REG-1 174 and REG-2). 176 The 2 levels of hierarchy within the HHIT allows for CAAs to have 177 their own Registered Assigning Authority (RAA) for their National Air 178 Space (NAS). Within the RAA, the CAAs can delegate HDAs as needed. 179 There may be other RAAs allowed to operate within a given NAS; this 180 is a policy decision by the CAA. 182 3.3. Remote ID Authentication using HHITs 184 The EdDSA25519 Host Identity (HI) underlying the HHIT is used for the 185 Message Wrapper, Sec 4.1 [drip-auth] (requirements GEN-2). It and 186 the HDA's HI/HHIT are used for the Offline Claim, sec 4.3 [drip-auth] 187 (requirements GEN-3). These messages also establish that the UA owns 188 the HHIT and that no other UA can assert ownership of the HHIT (GEN- 189 1). 191 The number of HDAs authorized to register UAs within an NAS 192 determines the size of the HDA credential cache a device processing 193 the Offline Authentication. This cache contains the HDA's HI/HHIT 194 and HDA meta-data; it could be very small. 196 4. UAS ID HHIT in DNS 198 There are 2 approaches for storing and retrieving the HHIT from DNS. 199 These are: 201 * As FQDNs in the .aero TLD. 203 * Reverse DNS lookups as IPv6 addresses per [RFC8005]. 205 The HHIT can be used to construct an FQDN that points to the USS that 206 has the Public/Private information for the UA (REG-1 and REG-2). For 207 example the USS for the HHIT could be found via the following. 208 Assume that the RAA is 100 and the HDA is 50. The PTR record is 209 constructed as: 211 100.50.hhit.uas.areo IN PTR foo.uss.areo. 213 The individual HHITs are potentially too numerous (e.g. 63M) and 214 dynamic to actually store in a signed, DNS zone. Rather the USS 215 would provide the HHIT detail response. 217 The HHIT reverse lookup can be a standard IPv6 reverse look up, or it 218 can leverage off the HHIT structure. Assume that the RAA is 10 and 219 the HDA is 20 and the HHIT is: 221 2001:14:28:14:a3ad:1952:ad0:a69e 223 An HHIT reverse lookup would be to is: 225 a69e.ad0.1952.a3ad14.28.14.2001.20.10.hhit.arpa. 227 5. Other UTM uses of HHITs 229 HHITs can be used extensively within the UTM architecture beyond for 230 UA ID (and USS in UA ID registration and authentication). The GCS 231 SHOULD have its own HHIT as an ID. It could use this if it is the 232 source of Network Remote ID for securing the transport and for secure 233 C2 transport [drip-secure-nrid-c2]. 235 Observers SHOULD have HHITs to facilitate UAS information retrieval 236 (e.g. for authorization to private UAS data). They could also use 237 their HHIT for establishing a HIP connection with the UA Pilot for 238 direct communications per authorization. Further, they can be used 239 by FINDER observers, [crowd-sourced-rid]. 241 6. DRIP Requirements addressed 243 This document provides solutions to GEN 1 - 3, ID 1 - 5, and REG 1 - 244 2. 246 7. ASTM Considerations 248 ASTM will need to make the following changes to the "UA ID" in the 249 Basic Message: 251 Type 4: 252 This document UA ID of Hierarchical HITs (see Section 3). 254 8. IANA Considerations 256 TBD 258 9. Security Considerations 260 The security considerations with Hierarchical HITs, most notably the 261 short hash of the HI, are discussed in [hierarchical-hit]. The 262 binding of the hierarchy to the hash of the HI is covered in 263 [new-orchid]. 265 Cryptographically Generated Addresses (CGAs) provide a unique 266 assurance of uniqueness. This is two-fold. The address (in this 267 case the UAS ID) is a hash of a public key and a Registry hierarchy 268 naming. Collision resistance (more important that its implied 269 second-preimage resistance) makes it statistically challenging to 270 attacks. A registration process as in HHIT Registries 271 [hhit-registries] provides a level of assured uniqueness unattainable 272 without mirroring this approach. 274 The second aspect of assured uniqueness is the digital signing 275 process of the HHIT by the HI private key and the further signing of 276 the HI public key by the Registry's key. This completes the 277 ownership process. The observer at this point does not know WHAT 278 owns the HHIT, but is assured, other than the risk of theft of the HI 279 private key, that this UAS ID is owned by something and is properly 280 registered. 282 9.1. Hierarchical HIT Trust 284 The HHIT UAS RID in the ASTM Basic Message (the actual Remote ID 285 message) does not provide any assertion of trust. The best that 286 might be done is 4 bytes truncated from a HI signing of the HHIT (the 287 UA ID field is 20 bytes and a HHIT is 16). It is in the ASTM 288 Authentication Messages as defined in [drip-auth] that provide all of 289 the actual ownership proofs. These claims include timestamps to 290 defend against replay attacks. But in themselves, they do not prove 291 which UA actually sent the message. They could have been sent by a 292 dog running down the street with a Broadcast Remote ID device 293 strapped to its back. 295 Proof of UA transmission comes when the Authentication Message 296 includes proofs for the Location/Vector Message and the observer can 297 see the UA or that information is validated by ground multilateration 298 [crowd-sourced-rid]. Only then does an observer gain full trust in 299 the HHIT Remote ID. 301 HHIT Remote IDs obtained via the Network Remote ID path provides a 302 different approach to trust. Here the UAS SHOULD be securely 303 communicating to the USS (see [drip-secure-nrid-c2]), thus asserting 304 HHIT RID trust. 306 10. Normative References 308 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 309 Requirement Levels", BCP 14, RFC 2119, 310 DOI 10.17487/RFC2119, March 1997, 311 . 313 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 314 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 315 May 2017, . 317 11. Informative References 319 [corus] CORUS, "U-space Concept of Operations", September 2019, 320 . 322 [crowd-sourced-rid] 323 Moskowitz, R., Card, S., Wiethuechter, A., Zhao, S., and 324 H. Birkholz, "Crowd Sourced Remote ID", Work in Progress, 325 Internet-Draft, draft-moskowitz-drip-crowd-sourced-rid-04, 326 20 May 2020, . 329 [CTA2063A] ANSI, "Small Unmanned Aerial Systems Serial Numbers", 330 September 2019. 332 [drip-auth] 333 Wiethuechter, A., Card, S., and R. Moskowitz, "DRIP 334 Authentication Formats", Work in Progress, Internet-Draft, 335 draft-wiethuechter-drip-auth-00, 23 March 2020, 336 . 339 [drip-requirements] 340 Card, S., Wiethuechter, A., and R. Moskowitz, "Drone 341 Remote Identification Protocol (DRIP) Requirements", Work 342 in Progress, Internet-Draft, draft-card-drip-reqs-02, 20 343 April 2020, 344 . 346 [drip-secure-nrid-c2] 347 Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov, 348 "Secure UAS Network RID and C2 Transport", Work in 349 Progress, Internet-Draft, draft-moskowitz-drip-secure- 350 nrid-c2-00, 6 April 2020, . 353 [F3411-19] ASTM International, "Standard Specification for Remote ID 354 and Tracking", February 2020, 355 . 357 [hhit-registries] 358 Moskowitz, R., Card, S., and A. Wiethuechter, 359 "Hierarchical HIT Registries", Work in Progress, Internet- 360 Draft, draft-moskowitz-hip-hhit-registries-02, 9 March 361 2020, . 364 [hierarchical-hit] 365 Moskowitz, R., Card, S., and A. Wiethuechter, 366 "Hierarchical HITs for HIPv2", Work in Progress, Internet- 367 Draft, draft-moskowitz-hip-hierarchical-hit-05, 13 May 368 2020, . 371 [new-hip-crypto] 372 Moskowitz, R., Card, S., and A. Wiethuechter, "New 373 Cryptographic Algorithms for HIP", Work in Progress, 374 Internet-Draft, draft-moskowitz-hip-new-crypto-04, 23 375 January 2020, . 378 [new-orchid] 379 Moskowitz, R., Card, S., and A. Wiethuechter, "Using 380 cSHAKE in ORCHIDs", Work in Progress, Internet-Draft, 381 draft-moskowitz-orchid-cshake-01, 21 May 2020, 382 . 385 [RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay 386 Routable Cryptographic Hash Identifiers Version 2 387 (ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September 388 2014, . 390 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 391 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 392 RFC 7401, DOI 10.17487/RFC7401, April 2015, 393 . 395 [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name 396 System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, 397 October 2016, . 399 Appendix A. EU U-Space RID Privacy Considerations 401 EU is defining a future of airspace management known as U-space 402 within the Single European Sky ATM Research (SESAR) undertaking. 403 Concept of Operation for EuRopean UTM Systems (CORUS) project 404 proposed low-level Concept of Operations [corus] for UAS in EU. It 405 introduces strong requirements for UAS privacy based on European GDPR 406 regulations. It suggests that UAs are identified with agnostic IDs, 407 with no information about UA type, the operators or flight 408 trajectory. Only authorized persons should be able to query the 409 details of the flight with a record of access. 411 Due to the high privacy requirements, a casual observer can only 412 query U-space if it is aware of a UA seen in a certain area. A 413 general observer can use a public U-space portal to query UA details 414 based on the UA transmitted "Remote identification" signal. Direct 415 remote identification (DRID) is based on a signal transmitted by the 416 UA directly. Network remote identification (NRID) is only possible 417 for UAs being tracked by U-Space and is based on the matching the 418 current UA position to one of the tracks. 420 The project lists "E-Identification" and "E-Registrations" services 421 as to be developed. These services can follow the privacy mechanism 422 proposed in this document. If an "agnostic ID" above refers to a 423 completely random identifier, it creates a problem with identity 424 resolution and detection of misuse. On the other hand, a classical 425 HIT has a flat structure which makes its resolution difficult. The 426 Hierarchical HITs provide a balanced solution by associating a 427 registry with the UA identifier. This is not likely to cause a major 428 conflict with U-space privacy requirements, as the registries are 429 typically few at a country level (e.g. civil personal, military, law 430 enforcement, or commercial). 432 Acknowledgments 434 Dr. Gurtov is an advisor on Cybersecurity to the Swedish Civil 435 Aviation Administration. 437 Authors' Addresses 439 Robert Moskowitz 440 HTT Consulting 441 Oak Park, MI 48237 442 United States of America 444 Email: rgm@labs.htt-consult.com 446 Stuart W. Card 447 AX Enterprize 448 4947 Commercial Drive 449 Yorkville, NY 13495 450 United States of America 452 Email: stu.card@axenterprize.com 454 Adam Wiethuechter 455 AX Enterprize 456 4947 Commercial Drive 457 Yorkville, NY 13495 458 United States of America 460 Email: adam.wiethuechter@axenterprize.com 462 Andrei Gurtov 463 Linköping University 464 IDA 465 SE-58183 Linköping 466 Sweden 468 Email: gurtov@acm.org