idnits 2.17.1 draft-moskowitz-tmrid-crowd-sourced-rid-01.txt: 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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (2 March 2020) is 1514 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) -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) -- Obsolete informational reference (is this intentional?): RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TMRID R. Moskowitz 3 Internet-Draft HTT Consulting 4 Intended status: Standards Track S. Card 5 Expires: 3 September 2020 A. Wiethuechter 6 AX Enterprize 7 2 March 2020 9 Crowd Sourced Remote ID 10 draft-moskowitz-tmrid-crowd-sourced-rid-01 12 Abstract 14 This document describes using the ASTM Broadcast Remote ID (B-RID) 15 specification in a "crowd sourced" smart phone environment to provide 16 much of the FAA mandated Network Remote ID (N-RID) functionality. 17 This crowd sourced B-RID data will use multi-lateration to add a 18 level of reliability in the location data on the Unmanned Aircraft 19 (UA). 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 3 September 2020. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Draft Status . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 58 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.1. Meeting the needs of Network ID . . . . . . . . . . . . . 5 61 3.2. Trustworthiness of Proxied Data . . . . . . . . . . . . . 6 62 3.3. Defense against fraudulent RID Messages . . . . . . . . . 6 63 4. The Finder - SPDP Security Relationship . . . . . . . . . . . 6 64 5. The CS-RID Messages . . . . . . . . . . . . . . . . . . . . . 7 65 5.1. CS-RID MESSAGE TYPE . . . . . . . . . . . . . . . . . . . 7 66 5.2. The CS-RID B-RID Proxy Message . . . . . . . . . . . . . 7 67 5.2.1. CS-RID ID . . . . . . . . . . . . . . . . . . . . . . 8 68 5.3. CS-RID Finder Registration . . . . . . . . . . . . . . . 8 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 7.1. Privacy Concerns . . . . . . . . . . . . . . . . . . . . 9 72 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 73 9. Normative References . . . . . . . . . . . . . . . . . . . . 9 74 10. Informative References . . . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 This document defines a mechanism to capture the ASTM Broadcast 80 Remote ID messages (B-RID) [WK65041] on any Internet connected device 81 that receives them and can forward them to the SPDP(s) responsible 82 for the geographic area the UA and receivers are in. This will 83 create a ecosystem that will meet most if not all data collection 84 requriments that CAAs are placing on Network Remote ID (N-RID). 86 These Internet connected devices are herein called "Finders", as they 87 find UAs by listening for B-RID messages. The Finders are B-RID 88 forwarding proxies. Their potentially limited spacial view of RID 89 messages could result in bad decisions on what messages to send to 90 the SPDP and which to drop. The SPDP will make any filtering 91 decisions in what it forwards to the UTM(s). 93 Finders can be smartphones, tablets, or any computing platform with 94 Internet connectivity that can meet the requirements defined in this 95 document. It is not expected, nor necessary, that Finders have any 96 information about a UAS beyond the content in the B-RID messages. 98 Finders MAY only need a loose association with the SPDP(s). They may 99 only have the SPDP's Public Key and FQDN. It would use these, along 100 with the Finder's Public Key to use ECIES, or other security methods, 101 to send the messages in a secure manner to the SPDP. The SPDP MAY 102 require a stronger relationship to the Finders. This may range from 103 the Finder's Public Key being registered to the SPDP with other 104 information so that the SPDP has some level of trust in the Finders 105 to requiring transmissions be sent over long-lived transport 106 connections like ESP or DTLS. 108 This document has minimal information about the actions of SPDPs. In 109 general the SPDP is out of scope of this document. That said, the 110 SPDPs should not simply proxy B-RID messages to the UTM(s). They 111 should perform some minimal level of filtering and content checking 112 before forwarding those messages that pass these tests in a secure 113 manner to the UTM(s). 115 An SPDP SHOULD only forward Authenticated B-RID messages like those 116 defined in [tmrid-auth] to the UTM(s). Further, the SPDP SHOULD 117 validate the Remote ID (RID) and the Authentication signature before 118 forwarding anything from the UA. 120 When 3 or more Finders are reporting to an SPDP on a specific UA, the 121 SPDP is in a unique position to perform multilateration on these 122 messages and compute the Finder's view of the UA location to compare 123 with the UA Location/Vector messages. This check against the UA's 124 location claims is both a validation on the UA's reliability as well 125 as the trustworthiness of the Finders. Other than providing data to 126 allow for multilateration, this SPDP feature is out of scope of this 127 document. 129 1.1. Draft Status 131 This draft was pushed out, in a largely raw state to meet the FAA's 132 NPRM for "Remote Identification of Unmanned Aircraft Systems" comment 133 filing deadline of March 2, 2020. 135 2. Terms and Definitions 137 2.1. Requirements Terminology 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 141 "OPTIONAL" in this document are to be interpreted as described in BCP 142 14 [RFC2119] [RFC8174] when, and only when, they appear in all 143 capitals, as shown here. 145 2.2. Definitions 147 B-RID 148 Broadcast Remote ID. A method of sending RID messages as 1-way 149 transmissions from the UA to any Observers within radio range. 151 CAA 152 Civil Aeronautics Administration. An example is the Federal 153 Aviation Administration (FAA) in the United States of America. 155 ECIES 156 Elliptic Curve Integrated Encryption Scheme. A hybrid encryption 157 scheme which provides semantic security against an adversary who 158 is allowed to use chosen-plaintext and chosen-ciphertext attacks. 160 GCS 161 Ground Control Station. The part of the UAS that the remote pilot 162 uses to exercise C2 over the UA, whether by remotely exercising UA 163 flight controls to fly the UA, by setting GPS waypoints, or 164 otherwise directing its flight. 166 Finder 167 In Internet connected device that can receive B-RID messages and 168 forward them to a UTM. 170 Observer 171 Referred to in other UAS documents as a "user", but there are also 172 other classes of RID users, so we prefer "observer" to denote an 173 individual who has observed an UA and wishes to know something 174 about it, starting with its RID. 176 Multilateration 177 Multilateration (more completely, pseudo range multilateration) is 178 a navigation and surveillance technique based on measurement of 179 the times of arrival (TOAs) of energy waves (radio, acoustic, 180 seismic, etc.) having a known propagation speed. 182 NETSP 183 Network RID Service Provider. USS receiving Network RID messages 184 from UAS (UA or GCS), storing for a short specified time, making 185 available to NETDP. 187 NETDP 188 Network RID Display Provider. Entity (might be USS) aggregating 189 data from multiple NETSPs to answer query from observer (or other 190 party) desiring Situational Awareness of UAS operating in a 191 specific airspace volume. 193 N-RID 194 Network Remote ID. A method of sending RID messages via the 195 Internet connection of the UAS directly to the UTM. 197 RID 198 Remote ID. A unique identifier found on all UA to be used in 199 communication and in regulation of UA operation. 201 SDSP 202 Supplemental Data Service Provider. Entity providing information 203 that is allowed, but not required to be present in the UTM system. 205 UA 206 Unmanned Aircraft. In this document UA's are typically though of 207 as drones of commerical or military variety. This is a very 208 strict definition which can be relaxed to include any and all 209 aircraft that are unmanned. 211 UAS 212 Unmanned Aircraft System. Composed of Unmanned Aircraft and all 213 required on-board subsystems, payload, control station, other 214 required off-board subsystems, any required launch and recovery 215 equipment, all required crew members, and C2 links between UA and 216 the control station. 218 UTM 219 UAS Traffic Management. A "traffic management" ecosystem for 220 uncontrolled operations that is separate from, but complementary 221 to, the FAA's Air Traffic Management (ATM) system. 223 USS 224 UAS Service Supplier. Provide UTM services to support the UAS 225 community, to connect Operators and other entities to enable 226 information flow across the USS network, and to promote shared 227 situational awareness among UTM participants. (From FAA UTM 228 ConOps V1, May 2018). 230 3. Problem Space 232 3.1. Meeting the needs of Network ID 234 The Federal (US) Aviation Authority (FAA), in the December 31, 2019 235 Remote ID Notice of Proposed Rulemaking (NPRM), is requiring 236 "Standard" and "Limited" Remote ID. Standard is when the UAS 237 provides both Network and Broadcast RID. Limited is when the UAS 238 provides only Network RID. The FAA has dropped their previous 239 position on allowing for only Broadcast RID. We can guess as to 240 their reasons; they are not spelled out in the NPRM. It may be that 241 just B-RID does not meet the FAA's statutory UA tracking 242 responsibility. 244 The UAS vendors have commented that N-RID places considerable demands 245 on currently used UAS. For some UAS like RC planes, meaningful N-RID 246 (via the Pilot's smartphone) are of limited value. A mechanism that 247 can augment B-RID to provide N-RID would help all members of the UAS 248 environment to provide safe operation and allow for new applications. 250 3.2. Trustworthiness of Proxied Data 252 When a proxy is introduced in any communication protocol, there is a 253 risk of corrupted data and DOS attacks. 255 3.3. Defense against fraudulent RID Messages 257 TBD 259 TBD 261 4. The Finder - SPDP Security Relationship 263 The SPDP(s) and Finders SHOULD use EDDSA keys as their trusted 264 Identities. The public keys SHOULD be registered Hierarchical HITS, 265 [hierarchical-hit] and [hhit-registries]. 267 The SPDP uses some process (out of scope here) to register the 268 Finders and there EDDSA Public Key. During this registration, the 269 Finder gets the SPDP's EDDSA Public Key. These Public Keys allow for 270 the following options for authenticated messaging from the Finder to 271 the SPDP. 273 1. ECIES can be used with a unique nonce to authenticate each 274 message sent from a Finder to the SPDP. 276 2. ECIES can be used at the start of some period (e.g. day) to 277 establish a shared secret that is then used to authenticate each 278 message sent from a Finder to the SPDP sent during that period. 280 3. HIPv2 [RFC7401] can be used to establish a session secret that is 281 then used with ESP [RFC4303] to authenticate each message sent 282 from a Finder to the SPDP. 284 4. DTLS [RFC5238] can be used to establish a secure connection that 285 is then used to authenticate each message sent from a Finder to 286 the SPDP. 288 5. The CS-RID Messages 290 The CS-RID messages between the Finders and the SPDPs primarily 291 support the proxy role of the Finders in forwarding the B-RID 292 messages. There are also Finder registration and status messages. 294 CS-RID information is represented in CBOR [RFC7049]. COSE [RFC8152] 295 may be used for CS-RID MAC and COAP [RFC7252] for the CS-RID 296 protocol. 298 The following is a general representation of the content in the CS- 299 RID messages. 301 ( CS-RID MESSAGE TYPE, 302 CS-RID MESSAGE CONTENT, 303 CS-RID MAC) 305 The CS-RID MESSAGE CONTENT varies by MESSAGE TYPE. 307 5.1. CS-RID MESSAGE TYPE 309 The CS-RID MESSAGE TYPE is: 311 Number CS-RID Message Type 312 ------ ----------------- 313 0 Reserved 314 1 B-RID Forwarding 315 2 Finder Registration 317 5.2. The CS-RID B-RID Proxy Message 319 The Finders add their own information to the B-RID messages, 320 permitting the SPDP(s) to gain additional knowledge about the UA(s). 321 The RID information is the B-RID message content plus the MAC 322 address. The MAC address is critical, as it is the only field that 323 links a UA's B-RID messages together. Only the ASTM Basic ID Message 324 and possibly the Authentication Message contain the UAS ID field. 326 The Finders add an SPDP assigned ID, a 64 bit timestamp, GPS 327 information, and type of B-RID media to the B-RID message. Both the 328 timestamp and GPS information are for when the B-RID message(s) were 329 received, not forwarded to the SPDP. All this content is MACed using 330 a key shared between the Finder and SPDP. 332 The following is a representation of the content in the CS-RID 333 messages. 335 ( CS-RID MESSAGE TYPE, 336 CS-RID ID, 337 RECEIVE TIMESTAMP, 338 RECEIVE GPS, 339 RECEIVE RADIO TYPE, 340 B-RID MAC ADDRESS, 341 B-RID MESSAGE, 342 CS-RID MAC) 344 TBD 346 5.2.1. CS-RID ID 348 The CS-RID ID is the ID recognized by the SPDP. This may be an HHIT 349 Hierarchical HITs [hierarchical-hit], or any ID used by the SPDP. 351 5.3. CS-RID Finder Registration 353 The CS-RID Finder MAY use HIPv2 [RFC7401] with the SPDP to establish 354 a Security Association and a shared secret to use for the CS-RID MAC 355 generation. In this approach, the HIPv2 mobility functionality and 356 ESP [RFC4303] support are not used. 358 When HIPv2 is used as above, the Finder Registration is a SPDP "wake 359 up". It is sent prior to the Finder sending any proxied B-RID 360 messages to ensure that the SPDP is able to receive and process the 361 messages. 363 In this usage, the CS-RID is the Finder HIT. If the SPDP has lost 364 state with the Finder, it initiates the HIP exchange with the Finder 365 to reestablish HIP state and a new shared secret for the CS-RID B-RID 366 Proxy Messages. In this case the Finder Registration Message is: 368 ( CS-RID MESSAGE TYPE, 369 CS-RID ID, 370 CS-RID MAC) 372 6. IANA Considerations 374 TBD 376 7. Security Considerations 378 TBD 380 7.1. Privacy Concerns 382 TBD 384 8. Acknowledgments 386 The Crowd Sourcing idea in this document came from the Apple "Find My 387 Device" presentation at the International Association for 388 Cryptographic Research's Real World Crypto 2020 conference. 390 9. Normative References 392 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 393 Requirement Levels", BCP 14, RFC 2119, 394 DOI 10.17487/RFC2119, March 1997, 395 . 397 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 398 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 399 May 2017, . 401 10. Informative References 403 [hhit-registries] 404 Moskowitz, R., Card, S., and A. Wiethuechter, 405 "Hierarchical HIT Registries", Work in Progress, Internet- 406 Draft, draft-moskowitz-hip-hhit-registries-01, 17 October 407 2019, . 410 [hierarchical-hit] 411 Moskowitz, R., Card, S., and A. Wiethuechter, 412 "Hierarchical HITs for HIPv2", Work in Progress, Internet- 413 Draft, draft-moskowitz-hip-hierarchical-hit-03, 16 414 December 2019, . 417 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 418 RFC 4303, DOI 10.17487/RFC4303, December 2005, 419 . 421 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 422 the Datagram Congestion Control Protocol (DCCP)", 423 RFC 5238, DOI 10.17487/RFC5238, May 2008, 424 . 426 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 427 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 428 October 2013, . 430 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 431 Application Protocol (CoAP)", RFC 7252, 432 DOI 10.17487/RFC7252, June 2014, 433 . 435 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 436 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 437 RFC 7401, DOI 10.17487/RFC7401, April 2015, 438 . 440 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 441 RFC 8152, DOI 10.17487/RFC8152, July 2017, 442 . 444 [tmrid-auth] 445 Wiethuechter, A., Card, S., and R. Moskowitz, "TM-RID 446 Authentication Formats", Work in Progress, Internet-Draft, 447 draft-wiethuechter-tmrid-auth-05, 18 February 2020, 448 . 451 [WK65041] ASTM, "Standard Specification for Remote ID and Tracking", 452 September 2019. 454 Authors' Addresses 456 Robert Moskowitz 457 HTT Consulting 458 Oak Park, MI 48237 459 United States of America 461 Email: rgm@labs.htt-consult.com 463 Stuart W. Card 464 AX Enterprize 465 4947 Commercial Drive 466 Yorkville, NY 13495 467 United States of America 469 Email: stu.card@axenterprize.com 471 Adam Wiethuechter 472 AX Enterprize 473 4947 Commercial Drive 474 Yorkville, NY 13495 475 United States of America 477 Email: adam.wiethuechter@axenterprize.com