idnits 2.17.1 draft-ietf-drip-auth-12.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 (25 May 2022) is 702 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: 'RFC8126' is mentioned on line 1244, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'F3411' Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DRIP Working Group A. Wiethuechter (Editor) 3 Internet-Draft S. Card 4 Intended status: Standards Track AX Enterprize, LLC 5 Expires: 26 November 2022 R. Moskowitz 6 HTT Consulting 7 25 May 2022 9 DRIP Entity Tag Authentication Formats & Protocols for Broadcast Remote 10 ID 11 draft-ietf-drip-auth-12 13 Abstract 15 This document describes how to include trust into the ASTM Remote ID 16 specification defined in ASTM F3411 under Broadcast Remote ID (RID). 17 It defines a few message schemes (sent within the Authentication 18 Message) that can be used to authenticate past messages sent by a 19 unmanned aircraft (UA) and provide proof of UA trustworthiness even 20 in the absence of Internet connectivity at the receiving node. 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 26 November 2022. 39 Copyright Notice 41 Copyright (c) 2022 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 Revised BSD License text as 50 described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Revised BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. DRIP Requirements Addressed . . . . . . . . . . . . . . . 4 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Required Terminology . . . . . . . . . . . . . . . . . . 4 59 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. Problem Space and Focus . . . . . . . . . . . . . . . . . 4 62 3.1.1. Broadcast RID RF Options . . . . . . . . . . . . . . 5 63 3.2. Reasoning for IETF DRIP Authentication . . . . . . . . . 5 64 3.3. ASTM Authentication Message . . . . . . . . . . . . . . . 5 65 3.3.1. Authentication Page . . . . . . . . . . . . . . . . . 5 66 3.3.2. ASTM Constraints . . . . . . . . . . . . . . . . . . 9 67 4. Forward Error Correction . . . . . . . . . . . . . . . . . . 9 68 4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 9 69 4.1.1. Single Page FEC . . . . . . . . . . . . . . . . . . . 10 70 4.1.2. Multiple Page FEC . . . . . . . . . . . . . . . . . . 10 71 4.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . . 13 72 4.2.1. Single Page FEC . . . . . . . . . . . . . . . . . . . 13 73 4.2.2. Multiple Page FEC . . . . . . . . . . . . . . . . . . 13 74 4.3. FEC Limitations . . . . . . . . . . . . . . . . . . . . . 14 75 5. DRIP Authentication Formats . . . . . . . . . . . . . . . . . 14 76 5.1. DRIP Authentication Field Definitions . . . . . . . . . . 14 77 5.1.1. Broadcast Attestation Structure . . . . . . . . . . . 15 78 5.1.2. SAM Data Format . . . . . . . . . . . . . . . . . . . 16 79 5.2. DRIP Link . . . . . . . . . . . . . . . . . . . . . . . . 18 80 5.3. DRIP Wrapper . . . . . . . . . . . . . . . . . . . . . . 18 81 5.3.1. Wrapper over Extended Transports . . . . . . . . . . 20 82 5.3.2. Wrapper Limitations . . . . . . . . . . . . . . . . . 21 83 5.4. DRIP Manifest . . . . . . . . . . . . . . . . . . . . . . 22 84 5.4.1. Hash Count . . . . . . . . . . . . . . . . . . . . . 23 85 5.4.2. Message Hash Algorithms and Operation . . . . . . . . 24 86 5.4.3. Pseudo-Blockchain Hashes . . . . . . . . . . . . . . 24 87 5.4.4. Manifest Limitations . . . . . . . . . . . . . . . . 25 88 5.5. DRIP Frame . . . . . . . . . . . . . . . . . . . . . . . 25 89 5.5.1. Frame Type . . . . . . . . . . . . . . . . . . . . . 26 90 6. Requirements & Recommendations . . . . . . . . . . . . . . . 27 91 6.1. Legacy Transports . . . . . . . . . . . . . . . . . . . . 27 92 6.2. Extended Transports . . . . . . . . . . . . . . . . . . . 27 93 6.3. Authentication . . . . . . . . . . . . . . . . . . . . . 27 94 6.4. Operational . . . . . . . . . . . . . . . . . . . . . . . 28 95 6.4.1. DRIP Wrapper . . . . . . . . . . . . . . . . . . . . 29 96 7. ICAO Considerations . . . . . . . . . . . . . . . . . . . . . 29 97 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 98 8.1. Update IANA DRIP Registry . . . . . . . . . . . . . . . . 29 99 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 100 9.1. Manifest Hash Length . . . . . . . . . . . . . . . . . . 30 101 9.2. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 31 102 9.3. Trust Timestamp Offsets . . . . . . . . . . . . . . . . . 31 103 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 104 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 105 11.1. Normative References . . . . . . . . . . . . . . . . . . 32 106 11.2. Informative References . . . . . . . . . . . . . . . . . 32 107 Appendix A. Authentication State Diagrams & Color Scheme . . . . 33 108 A.1. State Table . . . . . . . . . . . . . . . . . . . . . . . 33 109 A.2. State Diagrams . . . . . . . . . . . . . . . . . . . . . 34 110 A.2.1. Notations . . . . . . . . . . . . . . . . . . . . . . 34 111 A.2.2. General . . . . . . . . . . . . . . . . . . . . . . . 35 112 A.2.3. DRIP SAM . . . . . . . . . . . . . . . . . . . . . . 36 113 A.2.4. DRIP Link . . . . . . . . . . . . . . . . . . . . . . 37 114 A.2.5. DRIP Wrapper/Manifest/Frame . . . . . . . . . . . . . 38 115 Appendix B. HDA-UA Broadcast Attestation . . . . . . . . . . . . 40 116 Appendix C. Example TX/RX Flow . . . . . . . . . . . . . . . . . 42 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 119 1. Introduction 121 Unmanned Aircraft Systems (UAS) are usually in a volatile environment 122 when it comes to communication. UA are generally small with little 123 computational (or flying) horsepower to carry standard communication 124 equipment. This limits the mediums of communication to few viable 125 options. 127 Observer systems (e.g. smartphones and tablets) place further 128 constraints on the communication options. The Remote ID Broadcast 129 messages MUST be available to applications on these platforms without 130 modifying the devices. 132 The ASTM [F3411] standard focuses on two ways of communicating to a 133 UAS for Remote ID (RID): Broadcast and Network. 135 This document will focus on adding trust to Broadcast RID via the 136 Authentication Message by combining dynamically signed data with an 137 Attestation of the UA's identity from a Registry. 139 This authentication methodology also provides the missing, but US FAA 140 mandated, Error Correction for the Bluetooth 4 transmissions (see 141 Section 4). This is error correction not only for the authentication 142 message itself, but indirectly, to other messages authenticated via 143 the Manifest method (see Section 5.4). 145 1.1. DRIP Requirements Addressed 147 The following [drip-requirements] will be addressed: 149 GEN 1: Provable Ownership This will be addressed using the DRIP Link 150 and DRIP Wrapper or DRIP Manifest. 152 GEN 2: Provable Binding This requirement is addressed using the DRIP 153 Wrapper or DRIP Manifest. 155 GEN 3: Provable Registration This requirement is addressed using the 156 DRIP Link. 158 See Section 6.3 for further clarification. 160 2. Terminology 162 2.1. Required Terminology 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 166 "OPTIONAL" in this document are to be interpreted as described in BCP 167 14 [RFC2119] [RFC8174] when, and only when, they appear in all 168 capitals, as shown here. 170 2.2. Definitions 172 See [drip-requirements] for common DRIP terms. 174 Legacy Transports: uses broadcast frames (Bluetooth 4). 176 Extended Transports: uses the extended advertisements (Bluetooth 5), 177 service info (Wi-Fi NaN) or vendor specific element information 178 (Wi-Fi BEACON). Must use ASTM [F3411] Message Pack (Message Type 179 0xF). 181 3. Background 183 3.1. Problem Space and Focus 185 The current standard for Remote ID does not, in any meaningful 186 capacity, address the concerns of trust in the UA space with 187 communication in the Broadcast RID environment. This is a 188 requirement that will need to be addressed eventually for various 189 different parties that have a stake in the UA industry. 191 3.1.1. Broadcast RID RF Options 193 A UA has the option of broadcasting using Bluetooth (4 and 5) or Wi- 194 Fi (BEACON or NAN), see Section 6. With Bluetooth, FAA and other CAA 195 mandate transmitting simultaneously over both 4 and 5. With Wi-Fi, 196 use of BEACON is recommended. Wi-Fi NAN is another option, depending 197 on CAA. 199 Bluetooth 4 presents a payload size challenge in that it can only 200 transmit 25 bytes of payload where the others all can support 252 201 byte payloads. 203 3.2. Reasoning for IETF DRIP Authentication 205 The ASTM Authentication Message has provisions in [F3411] to allow 206 for other organizations to standardize additional Authentication 207 formats beyond those explicitly in [F3411]. The standardization of 208 specific formats to support the DRIP requirements in UAS RID for 209 trustworthy communications over Broadcast RID is an important part of 210 the chain of trust for a UAS ID. No existing formats (defined in 211 [F3411] or other organizations leveraging this feature) provide the 212 functionality to satisfy this goal resulting in the work reflected in 213 this document. 215 3.3. ASTM Authentication Message 217 The ASTM Authentication Message (Message Type 0x2) is a unique 218 message in the Broadcast [F3411] standard as it is the only one that 219 is larger than the Bluetooth 4 frame size. To address this, it is 220 defined as a set of "pages" that each fits into a single Bluetooth 4 221 broadcast frame. For other media these pages are still used but all 222 in a single frame. 224 3.3.1. Authentication Page 225 0 1 2 3 226 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 227 +---------------+---------------+---------------+---------------+ 228 | Page Header | | 229 +---------------+ | 230 | | 231 | | 232 | Authentication Payload | 233 | | 234 | | 235 +---------------+---------------+---------------+---------------+ 237 Page Header: (1 byte) 238 Authentication Type (4 bits) 239 Page Number (4 bits) 241 Authentication Payload: (23 bytes per page) 242 Authentication Payload, including headers. Null padded. 244 Figure 1: Standard ASTM Authentication Message Page 246 A single Authentication Message is akin to a UDP packet. The 247 Authentication Message is structured as a set of up to 16 pages. 248 Over Bluetooth 4, these pages are "fragmented" into separate 249 Bluetooth 4 broadcast frames. 251 Either as a single Authentication Message or a set of fragmented 252 Authentication Message Pages the structure(s) is further wrapped by 253 outer ASTM framing and the specific link framing (Bluetooth or Wi- 254 Fi). 256 3.3.1.1. Authentication Type 258 [F3411] has the following example subset of Authentication Type's 259 defined and that can be used in the Page Header: 261 +=====================+================================+ 262 | Authentication Type | Description | 263 +=====================+================================+ 264 | 0x2 | Operator ID Signature | 265 +---------------------+--------------------------------+ 266 | 0x3 | Message Set Signature | 267 +---------------------+--------------------------------+ 268 | 0x5 | Specific Authentication Method | 269 +---------------------+--------------------------------+ 271 Table 1 273 3.3.1.1.1. Specific Authentication Method (SAM) 275 This document leverages Authentication Type 0x5, Specific 276 Authentication Method (SAM), defining a set of SAM Types in 277 Section 5. 279 3.3.1.2. Page Number 281 There is a technical maximum of 16 pages (indexed 0 to 15 in the Page 282 Header) that can be sent for a single Authentication Message, with 283 each page carrying a max 23-byte Authentication Payload. See 284 Section 3.3.2 for more details. 286 3.3.1.3. Authentication Payload Field 288 The following is shown in its complete format. 290 0 1 2 3 291 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 292 +---------------+---------------+---------------+---------------+ 293 | Authentication Headers | 294 | +---------------+---------------+ 295 | | | 296 +---------------+---------------+ | 297 . . 298 . Authentication Data / Signature . 299 . . 300 | | 301 +---------------+---------------+---------------+---------------+ 302 | ADL | | 303 +---------------+ | 304 . . 305 . Additional Data . 306 . . 307 | | 308 +---------------+---------------+---------------+---------------+ 310 Authentication Headers: (6-bytes) 311 As defined in F3411. 313 Authentication Data / Signature: (255-bytes max) 314 Opaque authentication data. 316 Additional Data Length (ADL): (1-byte - unsigned) 317 Length in bytes of Additional Data. 319 Additional Data: (255-bytes max): 320 Data that follows the Authentication Data / Signature but 321 is not considered part of the Authentication Data. 323 Figure 2: ASTM Authentication Message Fields 325 Figure 2 is the source data view of the data fields found in the 326 Authentication Message as defined by [F3411]. This data is placed 327 into Figure 1's Authentication Payload, spanning multiple pages. 329 When Additional Data is being sent, a single unsigned byte 330 (Additional Data Length) directly follows the Authentication Data / 331 Signature and has the length, in bytes, of the following Additional 332 Data. For DRIP, this field is used to carry Forward Error Correction 333 as defined in Section 4. 335 3.3.2. ASTM Constraints 337 To keep consistent formatting across the different transports (Legacy 338 and Extended) and their independent restrictions the authentication 339 data being sent is REQUIRED to fit within the page limit of the most 340 constrained existing transport can support. Under Broadcast RID the 341 transport that can hold the least amount of authentication data is 342 Bluetooth 5 and Wi-Fi BEACON at 9-pages. 344 As such DRIP transmitters are REQUIRED to adhere to the following 345 when using the Authentication Message: 347 1. Authentication Data / Signature data MUST fit in the first 9 348 pages (Page Numbers 0 through 8). 350 2. The Length field in the Authentication Headers (which denotes the 351 length in bytes of Authentication Data / Signature only) MUST NOT 352 exceed the value of 201. 354 4. Forward Error Correction 356 For Broadcast RID, Forward Error Correction (FEC) is provided by the 357 lower layers in Extended Transports (Bluetooth 5, Wi-Fi NaN, and Wi- 358 Fi BEACON). The Bluetooth 4 Legacy Transport does not have 359 supporting FEC so with DRIP Authentication the following application 360 level FEC scheme is used to add FEC. This section is only used for 361 Bluetooth 4 transmission/reception. 363 The data added during FEC is not included in the Authentication Data 364 / Signature but instead in the Additional Data field of Figure 2. 365 This may cause the Authentication Message to exceed 9-pages, up to a 366 max of 16-pages. 368 4.1. Encoding 370 For any encoding the FEC data MUST start on a new ASTM Authentication 371 Page. To do this, null padding is added before the actual FEC data 372 starts and the length of the whole blob (null padding and FEC) is 373 used as the Additional Data Length. To properly fit FEC data into an 374 Authentication Page the number of parity-bytes is limited to 23 or a 375 multiple thereof (size of Authentication data per page). That is, 376 the Page Header (and anything before it) is omitted in the FEC 377 process. 379 4.1.1. Single Page FEC 381 To generate the parity a simple XOR operation using the previous and 382 current page is used. Only the 23-byte Authentication Page data is 383 used in the XOR operation. For Page 0, a 23-byte null pad is used 384 for the previous page. The resulting parity fills the last 23 bytes 385 of the Additional Data field of Figure 2 with the Additional Data 386 Length field being set to 23 or greater (depending on number of null 387 pad bytes are needed to get onto the next page). 389 Page N-1: 390 0 1 2 3 391 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 392 +---------------+---------------+---------------+---------------+ 393 | Page Header | | 394 +---------------+ | 395 | Authentication Data / Signature | 396 | | 397 | +---------------+---------------+---------------+ 398 | | ADL=33 | | 399 +---------------+---------------+ | 400 | Null Padding | 401 | | 402 +---------------+---------------+---------------+---------------+ 404 Page N: 405 0 1 2 3 406 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 407 +---------------+---------------+---------------+---------------+ 408 | Page Header | | 409 +---------------+ | 410 | | 411 | Forward Error Correction | 412 | | 413 | | 414 | | 415 +---------------+---------------+---------------+---------------+ 417 Figure 3: Example Single Page FEC Encoding 419 4.1.2. Multiple Page FEC 421 For Multiple Page FEC there are two flavors: Frame Recovery and Page 422 Recovery. Both follow a similar process, but are offset at what data 423 is actually protected. 425 (Editor Note: to improve interop we MUST explicitly select a 426 polynomial for Reed Solomon for DRIP - need suggestions) 428 4.1.2.1. Page Recovery 430 Take the following example of an Authentication Message with 7 pages 431 that 3 pages of parity are to be generated for. The first column is 432 just the Page Header with a visual space here to show the boundary. 434 50 098960bf8c05042001001000a00145aac6b00abba268b7 435 51 2001001000a0014579d8a404d48f2ef9bb9a4470ada5b4 436 52 ff1352c7402af9d9ebd20034e8d7a12920f4d7e91c1a73 437 53 dca7d04e776150825863c512c6eb075a206a95c59b297e 438 54 f2935fd416f27b1b42fd5d9dfaa0dec79f32287f41b454 439 55 7101415def153a770d3e6c0b17ae560809bc634a822c1f 440 56 3b1064b80a000000000000000000000000000000000000 442 For Page Recovery the first column is ignored and the last 23-bytes 443 of each page are extracted to have Reed Solomon performed on them in 444 a column wise fashion to produce parity bytes. For the example the 445 following 3-bytes of parity are generated with the first byte of each 446 page: 448 dc6c2b = ReedSolomon.encoder(0920ffdcf2713b) 450 Each set of parity is the placed into a pseudo-frame as follows (each 451 byte in its own message in the same column). Below is an example of 452 the full parity generated and each 23-bytes of parity added into the 453 additional pages as Additional Data: 455 57 dc6657acd30b2ec4aa582049f52adf9f922e62c469563a 456 58 6c636a59145a55417a3895fd543f19e94200be4abc5e94 457 59 02bba5e28f5896d754caf50016a983993b149b5c9e6eeb 459 4.1.2.2. Frame Recovery 461 Frame Recovery uses the full ASTM Message and performs Reed Solomon 462 over each byte. Up to 240 (255 minus 15 pages max of FEC data) 463 messages can be protected using Frame Recovery. 465 Below is an example of a number of messages. Here the first column 466 is an additional ASTM Header that contain the Message Type; with a 467 visual space for clarity. The last 24-bytes are the actual message 468 contents; be it location information or an Authentication Page. 470 10 42012001001000a0014579d8a404d48f2ef9000000000000 471 11 249600006efeb019ee111ed37a097a0948081c10ffff0000 472 12 50098960bf8c05042001001000a00145aac6b00abba268b7 473 12 512001001000a0014579d8a404d48f2ef9bb9a4470ada5b4 474 12 52ff1352c7402af9d9ebd20034e8d7a12920f4d7e91c1a73 475 12 53dca7d04e776150825863c512c6eb075a206a95c59b297e 476 12 54f2935fd416f27b1b42fd5d9dfaa0dec79f32287f41b454 477 12 557101415def153a770d3e6c0b17ae560809bc634a822c1f 478 12 563b1064b80a000000000000000000000000000000000000 479 13 0052656372656174696f6e616c2054657374000000000000 480 14 02c2ffb019322d1ed3010000c008e40700fc080000000000 481 15 004e2e4f5031323334353600000000000000000000000000 483 A similar process is followed as in Section 4.1.2.1. Here every 484 column of bytes has parity generated for it (even the ASTM Header). 485 In the below example 5-bytes of parity are generated using the ASTM 486 Header column: 488 6c3f42b8a8 = ReedSolomon.encoder(101112121212121212131415) 490 After doing this to all columns the following pseudo-frames would 491 have been generated: 493 6c86337bf7ab746f5d62bb7f8de954104b121585d3975f6e92 494 3f06c1bce165b0e25930d57a63c24f751145e1dd8dc115029b 495 42e9979580327a6a14d421c12a33aa2e1a2e517daaee581016 496 b8012a7b3964f7b2720d387bfa77e945556f1831cd477ef3a3 497 a85bb403aada89926fb8fc2a14a9caacb4ec2f3a6ed2d8e9f9 499 These 25-byte chunks are now concatenated together and are placed in 500 Authentication Pages, using the Additional Data, 23-bytes at a time. 501 In the below figure the first column is the ASTM Header as before, 502 the second column is the Page Header for each Authentication Page and 503 then last column is the 23-bytes of data for each page. 505 12 57 6c86337bf7ab746f5d62bb7f8de954104b121585d3975f 506 12 58 6e923f06c1bce165b0e25930d57a63c24f751145e1dd8d 507 12 59 c115029b42e9979580327a6a14d421c12a33aa2e1a2e51 508 12 5a 7daaee581016b8012a7b3964f7b2720d387bfa77e94555 509 12 5b 6f1831cd477ef3a3a85bb403aada89926fb8fc2a14a9ca 510 12 5c acb4ec2f3a6ed2d8e9f900000000000000000000000000 512 4.2. Decoding 514 Due to the nature of Bluetooth 4 and the existing ASTM paging 515 structure an optimization can be used. If a Bluetooth frame fails 516 its CRC check, then the frame is dropped without notification to the 517 upper protocol layers. From the Remote ID perspective this means the 518 loss of a complete frame/message/page. In Authentication Messages, 519 each page is already numbered so the loss of a page allows the 520 receiving application to build a "dummy" page filling the entire page 521 with nulls. 523 If Page 0 is being reconstructed an additional check of the Last Page 524 Index to check against how many pages are actually present, MUST be 525 performed for sanity. An additional check on the Length field SHOULD 526 also be performed. 528 To determine if Single Page FEC or Multiple Page FEC has been used a 529 simple check of the Last Page Index can be used. If the number of 530 pages left after the Length of Authentication Data is exhausted than 531 it is clear that the remaining pages are all FEC. The Additional 532 Data Length byte can further confirm this; taking into account any 533 null padding needed for page alignment. 535 4.2.1. Single Page FEC 537 Using the same methods as encoding, an XOR operation is used between 538 the previous and current page (a 23-byte null pad is used as the 539 start). The resulting 23-bytes should be data of the missing page. 541 4.2.2. Multiple Page FEC 543 To determine if Page Recovery or Frame Recovery is used two modulo 544 checks with the ADL after the length of the null-pad is removed are 545 needed. One against the value of 23, and the other against the value 546 of 25. If 23 comes back with a value of 0 then Page Recovery is 547 being used. If 25 comes back with 0 then Frame Recovery is used. 548 Any other combination indicates an error. 550 4.2.2.1. Page Recovery 552 To decode Page Recovery, dummy pages (pages with nulls as the data) 553 are needed in the places no page was received. Then Reed Solomon can 554 decode across the columns of the 23-bytes of each page. Erasures can 555 be used as it is known which pages are missing and can improve the 556 Reed Solomon results by specifying them. 558 4.2.2.2. Frame Recovery 560 To decode Frame Recovery, the receiver must first extract all FEC 561 data from the pages; concatenate them and then break into 25-byte 562 chunks. This will produce the pseudo-frames. Now Reed Solomon can 563 be used to decode columns, with dummy frames inserted where needed. 565 4.3. FEC Limitations 567 The worst case scenario is when the Authentication Data / Signature 568 ends perfectly on a page (Page N-1). This means the Additional Data 569 Length would start the next page (Page N) and have 22-bytes worth of 570 null padding to align the FEC in to the next page (Page N+1). In 571 this scenario an entire page (Page N) is being wasted just to carry 572 the Additional Data Length. This should be be avoided at all costs - 573 in an effort to maintain efficiency. 575 5. DRIP Authentication Formats 577 All formats defined in this section are the content for the 578 Authentication Data / Signature field in Figure 2 and uses the 579 Specific Authentication Method (SAM, Authentication Type 0x5). The 580 first byte of the Authentication Data / Signature of Figure 2, is 581 used to multiplex between these various formats. 583 When sending data over a medium that does not have underlying Forward 584 Error Correction (FEC), for example Bluetooth 4, then Section 4 MUST 585 be used. 587 5.1. DRIP Authentication Field Definitions 589 ASTM Message (25-bytes): Full ASTM Message as defined in [F3411] 590 specifically Message Types 0x0, 0x1, 0x3, 0x4, and 0x5 592 ASTM Message Hash (12-bytes): Hash of a single full ASTM Message 593 using hash operations described in (Section 5.4.2). Multiple 594 hashes MUST be in Message Type order. 596 Attestation Data (0 to 112 bytes): Opaque attestation data that the 597 UA is attesting during its flight in Figure 4. 599 Broadcast Attestation (136-bytes): HDA HI over UA DET/HI. Generated 600 by a DRIP Registry during Session ID registration. Used in 601 Section 5.2. 603 Current Manifest Hash (12-bytes): See Section 5.4.3. 605 Frame Type (1-byte): Sub-type for future different DRIP Frame 606 formats. See Section 5.5.1. 608 Not Before Timestamp by UA (4-bytes): Timestamp denoting recommended 609 time to start trusting data in Figure 4. MUST follow the format 610 defined in [F3411]. That is a Unix-style timestamp but with an 611 epoch of 01/01/2019 00:00:00. MUST be set to the time the 612 signature is generated. 614 Not After Timestamp by UA (4-bytes): Timestamp denoting recommended 615 time to stop trusting data in Figure 4. MUST follow the format 616 defined in [F3411]. That is a Unix-style timestamp but with an 617 epoch of 01/01/2019 00:00:00 with an additional offset is then 618 added to push a short time into the future (relative to Not Before 619 Timestamp) to avoid replay attacks. The offset used against the 620 Unix-style timestamp is not defined in this document. Best 621 practice identifying an acceptable offset should be used taking 622 into consideration the UA environment, and propagation 623 characteristics of the messages being sent and clock differences 624 between the UA and Observers. A reasonable time would be to set 625 Not After Timestamp 2 minutes ahead of Not Before Timestamp. 627 Previous Manifest Hash (12-bytes): See Section 5.4.3. 629 UA DRIP Entity Tag (16-bytes): The UA DET in byte form (network byte 630 order) and is part of Figure 4. 632 UA Signature (64-bytes): Signature over preceding fields of Figure 4 633 using the HI of the UA. 635 5.1.1. Broadcast Attestation Structure 637 To directly support Broadcast RID a variation of the Attestation 638 Structure format of [drip-registries] SHOULD be used when running 639 DRIP under the various SAM Types (filling the SAM Authentication Data 640 field (Section 5.1.2.2)). The notable changes of the structure is 641 that the timestamps are set by the UA and the Attestor Identity 642 Information is set to the DET of the UA. 644 When using this structure the UA is always self-attesting its DRIP 645 Entity Tag (DET). The Host Identity of the UA DET can be looked up 646 by mechanisms described in [drip-registries] or by extracting it from 647 Broadcast Attestation (see Section 5.2 and Section 6.3). 649 0 1 2 3 650 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 651 +---------------+---------------+---------------+---------------+ 652 | | 653 | UA | 654 | DRIP Entity Tag | 655 | | 656 +---------------+---------------+---------------+---------------+ 657 | | 658 . . 659 . Attestation Data . 660 . . 661 | | 662 +---------------+---------------+---------------+---------------+ 663 | Not Before Timestamp by UA | 664 +---------------+---------------+---------------+---------------+ 665 | Not After Timestamp by UA | 666 +---------------+---------------+---------------+---------------+ 667 | | 668 | | 669 | | 670 | | 671 | | 672 | | 673 | | 674 | UA Signature | 675 | | 676 | | 677 | | 678 | | 679 | | 680 | | 681 | | 682 | | 683 +---------------+---------------+---------------+---------------+ 685 Figure 4: Broadcast Attestation Structure 687 5.1.2. SAM Data Format 689 Figure 5 is the general format to hold authentication data when using 690 SAM and is placed inside the Authentication Data / Signature field in 691 Figure 2. 693 0 1 2 3 694 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 695 +---------------+---------------+---------------+---------------+ 696 | SAM Type | | 697 +---------------+ | 698 . . 699 . SAM Authentication Data . 700 . . 701 | | 702 +---------------+---------------+---------------+---------------+ 704 SAM Type (1 byte): 705 Byte defined by F3411 to multiplex SAMs 707 SAM Authentication Data (0 to 200 bytes): 708 Opaque SAM authentication data. 710 Figure 5: SAM Data Format 712 5.1.2.1. SAM Type 714 The SAM Type field is maintained by the International Civil Aviation 715 Organization (ICAO) and for DRIP four are planned to be allocated: 717 +==========+=============================+ 718 | SAM Type | Description | 719 +==========+=============================+ 720 | 0x01 | DRIP Link (Section 5.2) | 721 +----------+-----------------------------+ 722 | 0x02 | DRIP Wrapper (Section 5.3) | 723 +----------+-----------------------------+ 724 | 0x03 | DRIP Manifest (Section 5.4) | 725 +----------+-----------------------------+ 726 | 0x04 | DRIP Frame (Section 5.5) | 727 +----------+-----------------------------+ 729 Table 2 731 5.1.2.2. SAM Authentication Data 733 This field has a maximum size of 200-bytes, as defined by 734 Section 3.3.2. The Broadcast Attestation Structure (Section 5.1.1) 735 SHOULD be used in this space. 737 5.2. DRIP Link 739 This SAM Type is used to transmit Broadcast Attestation's. For 740 example, the Broadcast Attestation of the Registry (HDA) over the UA 741 is sent (see Section 6.3) as a DRIP Link message. Its structure is 742 defined in [drip-registries] and an example of it can be found in 743 Appendix B. 745 DRIP Link is important as its contents are used to provide trust in 746 the DET/HI that the UA is currently broadcasting. This message does 747 not require internet connectivity to perform signature validations of 748 the contents when the registry DET/HI is in the receivers cache. It 749 also provides the UA HI so that connectivity is not required when 750 performing validation of other DRIP Authentication Messages. 752 0 1 2 3 753 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 754 +---------------+---------------+---------------+---------------+ 755 | | 756 . . 757 . Broadcast Attestation . 758 . . 759 | | 760 +---------------+---------------+---------------+---------------+ 762 Figure 6: DRIP Link 764 This DRIP Authentication Message is used in conjunction with other 765 DRIP SAM Types (such as Manifest or Wrapper) that contain data that 766 is guaranteed to be unique and easily cross checked by the receiving 767 device. A good candidate for this is using the DRIP Wrapper to 768 encapsulate a Location Message (Message Type 0x2). 770 5.3. DRIP Wrapper 772 This SAM Type is used to wrap and sign over a list of other [F3411] 773 Broadcast RID messages. It MUST use the Broadcast Attestation 774 Structure (Section 5.1.1). 776 The Attestation Data field is filled with full (25-byte) [F3411] 777 Broadcast RID messages. The minimum number being 1 and the maximum 778 being 4. The encapsulated messages MUST be in Message Type order as 779 defined by [F3411]. All message types except Authentication (Message 780 Type 0x2) and Message Pack (Message Type 0xF) are allowed. 782 To determine the number of messages wrapped the receiver can check 783 that the length of the Attestation Data field of the DRIP Broadcast 784 Attestation (Section 5.1.1) is a multiple of 25-bytes. 786 0 1 2 3 787 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 788 +---------------+---------------+---------------+---------------+ 789 | | 790 | UA | 791 | DRIP Entity Tag | 792 | | 793 +---------------+---------------+---------------+---------------+ 794 | | 795 | | 796 | ASTM Message | 797 | | 798 | | 799 | | 800 + +---------------+---------------+---------------+ 801 | | | 802 +---------------+ | 803 | | 804 | ASTM Message | 805 | | 806 | | 807 | | 808 + +---------------+---------------+ 809 | | | 810 +---------------+---------------+ | 811 | | 812 | | 813 | ASTM Message | 814 | | 815 | | 816 + +---------------+ 817 | | | 818 +---------------+---------------+---------------+ | 819 | | 820 | | 821 | ASTM Message | 822 | | 823 | | 824 | | 825 +---------------+---------------+---------------+---------------+ 826 | Not Before Timestamp by UA | 827 +---------------+---------------+---------------+---------------+ 828 | Not After Timestamp by UA | 829 +---------------+---------------+---------------+---------------+ 830 | | 831 | | 832 | | 833 | | 834 | | 835 | | 836 | | 837 | UA Signature | 838 | | 839 | | 840 | | 841 | | 842 | | 843 | | 844 | | 845 | | 846 +---------------+---------------+---------------+---------------+ 848 Figure 7: Example 4-Message DRIP Wrapper 850 5.3.1. Wrapper over Extended Transports 852 To send the DRIP Wrapper over Extended Transports the messages being 853 wrapped are co-located with the Authentication Message in a Message 854 Pack (0xF). The ASTM Messages are removed from the DRIP Wrapper 855 after signing (as they are redundant) leaving the following structure 856 that is placed into the SAM Authentication Data of Figure 5 and sent 857 in the same Message Pack. 859 0 1 2 3 860 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 861 +---------------+---------------+---------------+---------------+ 862 | | 863 | UA | 864 | DRIP Entity Tag | 865 | | 866 +---------------+---------------+---------------+---------------+ 867 | Not Before Timestamp by UA | 868 +---------------+---------------+---------------+---------------+ 869 | Not After Timestamp by UA | 870 +---------------+---------------+---------------+---------------+ 871 | | 872 | | 873 | | 874 | | 875 | | 876 | | 877 | | 878 | UA Signature | 879 | | 880 | | 881 | | 882 | | 883 | | 884 | | 885 | | 886 | | 887 +---------------+---------------+---------------+---------------+ 889 Figure 8: DRIP Wrapper under Extended Transports 891 To verify the signature the receiver must concatenate all of the 892 messages in the Message Pack (excluding Authentication Message found 893 in the same Message Pack) in Message Type order and place the blob 894 between the UA DRIP Entity Tag and Not Before Timestamp before 895 performing signature verification. 897 5.3.2. Wrapper Limitations 899 The primary limitation of the Wrapper format is the bounding of up to 900 4 ASTM Messages that can be sent within it. Another limitation is 901 that the format can not be used as a surrogate for messages it is 902 wrapping. This is due to high potential a receiver on the ground 903 does not support DRIP. Thus when Wrapper is being used the wrapper 904 data must effectively be sent twice; once as a single framed message 905 (as specified in [F3411]) and then again wrapped within the Wrapper 906 format. 908 5.4. DRIP Manifest 910 This SAM Type is used to create message manifests. It MUST use the 911 Broadcast Attestation Structure (Section 5.1.1). 913 By hashing previously sent messages and signing them we gain trust in 914 UAs previous reports. An observer who has been listening for any 915 length of time can hash received messages and cross-check against 916 listed hashes. This is a way to evade the limitation of a maximum of 917 4 messages in the Wrapper Format and reduce overhead. 919 The Attestation Data field is filled with 12-byte hashes of previous 920 [F3411] Broadcast messages. A receiver does not need to have 921 received every message in the manifest to verify it. A manifest 922 SHOULD typically encompass a single transmission cycle of messages 923 being sent, see Section 6.4. 925 0 1 2 3 926 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 927 +---------------+---------------+---------------+---------------+ 928 | | 929 | UA | 930 | DRIP Entity Tag | 931 | | 932 +---------------+---------------+---------------+---------------+ 933 | | 934 | Previous Manifest Hash | 935 | | 936 +---------------+---------------+---------------+---------------+ 937 | | 938 | Current Manifest Hash | 939 | | 940 +---------------+---------------+---------------+---------------+ 941 | | 942 | ASTM Message Hash | 943 | | 944 +---------------+---------------+---------------+---------------+ 945 | | 946 | ASTM Message Hash | 947 | | 948 +---------------+---------------+---------------+---------------+ 949 | | 950 | ASTM Message Hash | 951 | | 952 +---------------+---------------+---------------+---------------+ 953 | | 954 | ASTM Message Hash | 955 | | 956 +---------------+---------------+---------------+---------------+ 957 | | 958 | ASTM Message Hash | 959 | | 960 +---------------+---------------+---------------+---------------+ 961 | | 962 | ASTM Message Hash | 963 | | 964 +---------------+---------------+---------------+---------------+ 965 | | 966 | ASTM Message Hash | 967 | | 968 +---------------+---------------+---------------+---------------+ 969 | Not Before Timestamp by UA | 970 +---------------+---------------+---------------+---------------+ 971 | Not After Timestamp by UA | 972 +---------------+---------------+---------------+---------------+ 973 | | 974 | | 975 | | 976 | | 977 | | 978 | | 979 | | 980 | UA Signature | 981 | | 982 | | 983 | | 984 | | 985 | | 986 | | 987 | | 988 | | 989 +---------------+---------------+---------------+---------------+ 991 Figure 9: Example DRIP Manifest 993 5.4.1. Hash Count 995 The number of hashes in the Manifest can be variable (3-9). An easy 996 way to determine the number of hashes is to take the length of the 997 data between the end of the UA DRIP Entity Tag and Not Before 998 Timestamp by UA and divide it by the hash length (12). If this value 999 is not rational, the message is invalid. 1001 5.4.2. Message Hash Algorithms and Operation 1003 The hash algorithm used for the Manifest Message is the same hash 1004 algorithm used in creation of the DET [drip-rid] that is signing the 1005 Manifest. 1007 An DET using cSHAKE128 [NIST.SP.800-185] computes the hash as 1008 follows: 1010 cSHAKE128(ASTM Message, 96, "", "Remote ID Auth Hash") 1012 Note: [drip-rid] specifies cSHAKE128 but is open for the 1013 expansion of other OGAs. 1015 5.4.2.1. Legacy Transport Hashing 1017 Under this transport DRIP hashes the full ASTM Message being sent 1018 over the Bluetooth Advertising frame. For Authentication Messages 1019 all the Authentication Message Pages are concatenated together and 1020 hashed as one object. For all other Message Types the 25-byte 1021 message is hashed. 1023 5.4.2.2. Extended Transport Hashing 1025 Under this transport DRIP hashes the full ASTM Message Pack (Message 1026 Type 0xF) - regardless of its content. 1028 5.4.3. Pseudo-Blockchain Hashes 1030 Two special hashes are included in all Manifest messages; a previous 1031 manifest hash, which links to the previous manifest message, as well 1032 as a current manifest hash. This gives a pseudo-blockchain 1033 provenance to the manifest message that could be traced back if the 1034 observer was present for extended periods of time. 1036 Creation: During creation and signing of this message format this 1037 field MUST be set to 0. So the signature will be based on this 1038 field being 0, as well as its own hash. It is an open question of 1039 if we compute the hash, then sign or sign then compute. 1041 Cycling: There a few different ways to cycle this message. We can 1042 "roll up" the hash of 'current' to 'previous' when needed or to 1043 completely recompute the hash. This mostly depends on the 1044 previous note. 1046 5.4.4. Manifest Limitations 1048 A potential limitation to this format is dwell time of the UA. If 1049 the UA is not sticking to a general area then most likely the 1050 Observer will not obtain many (if not all) of the messages in the 1051 manifest. Examples of such scenarios include delivery or survey UA. 1053 Another limitation is the length of hash, which is discussed in 1054 Section 9.1. 1056 5.5. DRIP Frame 1058 This SAM Type is for when the authentication data does not fit in 1059 other defined formats under DRIP and is reserved for future expansion 1060 under DRIP if required. This SAM Type MUST use the Broadcast 1061 Attestation Structure (Section 5.1.1). 1063 0 1 2 3 1064 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1065 +---------------+---------------+---------------+---------------+ 1066 | | 1067 | UA | 1068 | DRIP Entity Tag | 1069 | | 1070 +---------------+---------------+---------------+---------------+ 1071 | Frame Type | | 1072 +---------------+ . 1073 . Frame Attestation Data . 1074 . . 1075 | | 1076 +---------------+---------------+---------------+---------------+ 1077 | Not Before Timestamp by UA | 1078 +---------------+---------------+---------------+---------------+ 1079 | Not After Timestamp by UA | 1080 +---------------+---------------+---------------+---------------+ 1081 | | 1082 | | 1083 | | 1084 | | 1085 | | 1086 | | 1087 | | 1088 | UA Signature | 1089 | | 1090 | | 1091 | | 1092 | | 1093 | | 1094 | | 1095 | | 1096 | | 1097 +---------------+---------------+---------------+---------------+ 1099 Figure 10: Example DRIP Frame 1101 5.5.1. Frame Type 1103 Byte to sub-type for future different DRIP Frame formats. It takes 1104 the first byte of Attestation Data in Section 5.1.1 leaving 111-bytes 1105 for Frame Attestation Data. 1107 +============+==============+==================+ 1108 | Frame Type | Name | Description | 1109 +============+==============+==================+ 1110 | 0x00 | Reserved | Reserved | 1111 +------------+--------------+------------------+ 1112 | 0xC0-0xFF | Experimental | Experimental Use | 1113 +------------+--------------+------------------+ 1115 Table 3 1117 6. Requirements & Recommendations 1119 6.1. Legacy Transports 1121 With Legacy Advertisements the goal is to attempt to bring reliable 1122 receipt of the paged Authentication Message. FEC (Section 4) MUST be 1123 used, per mandated Remote ID rules (for example the US FAA Remote ID 1124 Rule [faa-rid]), when using Legacy Advertising methods (such as 1125 Bluetooth 4). 1127 Under ASTM Bluetooth 4 rules, transmission of dynamic messages are at 1128 least every 1 second. DRIP Authentication Messages typically contain 1129 dynamic data (such as the DRIP Manifest or DRIP Wrapper) and must be 1130 sent at the dynamic rate of 1 per second. 1132 6.2. Extended Transports 1134 Under the ASTM specification, Bluetooth 5, Wi-Fi NaN, and Wi-Fi 1135 BEACON transport of Remote ID is to use the Message Pack (Message 1136 Type 0xF) format for all transmissions. Under Message Pack messages 1137 are sent together (in Message Type order) in a single Bluetooth 5 1138 extended frame (up to 9 single frame equivalent messages under 1139 Bluetooth 4). Message Packs are required by ASTM to be sent at a 1140 rate of 1 per second (like dynamic messages). 1142 Without any fragmentation or loss of pages with transmission Forward 1143 Error Correction (Section 4) MUST NOT be used as it is impractical. 1145 6.3. Authentication 1147 It is REQUIRED that a UA send the following Authentication Formats to 1148 fulfill the [drip-requirements]: 1150 1. DRIP Link using the Broadcast Attestation of HDA and the UA 1151 (satisfying GEN-1 and GEN-3) 1153 2. Any other DRIP Authentication Format (RECOMMENDED: DRIP Manifest 1154 or DRIP Wrapper) where the UA is dynamically signing data that is 1155 guaranteed to be unique and easily cross checked by the receiving 1156 device (satisfying GEN-1 and GEN-2) 1158 It is RECOMMENDED the following set of Authentication Formats are 1159 sent for support of offline Observers: 1161 1. DRIP Link using the Broadcast Attestation of HID Root and the RAA 1162 (CAA) (satisfies GEN-3) 1164 2. DRIP Link using the Broadcast Attestation of RAA (CAA) and the 1165 HDA (USS) (satisfies GEN-3) 1167 3. DRIP Link using the Broadcast Attestation of HDA (USS) and the UA 1168 (satisfies GEN-1 and GEN-3) 1170 4. Any other DRIP Authentication Format (RECOMMENDED: DRIP Manifest 1171 or DRIP Wrapper) where the UA is dynamically signing data that is 1172 guaranteed to be unique and easily cross checked by the receiving 1173 device (satisfying GEN-1 and GEN-2) 1175 6.4. Operational 1177 UAS operation may impact the frequency of sending DRIP Authentication 1178 messages. Where a UA is dwelling in one location, and the channel is 1179 heavily used by other devices, "occasional" message authentication 1180 may be sufficient for an observer. Contrast this with a UA 1181 traversing an area, and then every message should be authenticated as 1182 soon as possible for greatest success as viewed by the receiver. 1184 Thus how/when these DRIP authentication messages are sent is up to 1185 each implementation. Further complication comes in contrasting 1186 Legacy and Extended Transports. In Legacy, each message is a 1187 separate hash within the Manifest. So, again in dwelling, may lean 1188 toward occasional message authentication. In Extended Transports, 1189 the hash is over the Message Pack so only few hashes need to be in a 1190 Manifest. A single Manifest can handle a potential two Message Packs 1191 (for a full set of messages) and a DRIP Link Authentication Message 1192 for the HDA UA assertion. 1194 A separate issue is the frequency of transmitting the DRIP Link 1195 Authentication Message for the HDA UA assertion when using a Manifest 1196 Message. This message content is static; its hash never changes 1197 radically. The only change is the 4-byte timestamp in the 1198 Authentication Message headers. Thus, potentially, in a dwelling 1199 operation it can be sent once per minute, where its hash is in every 1200 Manifest. A receiver can cache all DRIP Link Authentication Message 1201 for the HDA UA assertion to mitigate potential packet loss. 1203 The preferred mode of operation is to send the HDA UA assertion every 1204 3 seconds and Manifest messages immediately after a set of UA 1205 operation messages (e.g. Basic, Location, and System messages). 1207 6.4.1. DRIP Wrapper 1209 The DRIP Wrapper MUST NOT be used in place of sending the ASTM 1210 messages as is. All receivers MUST be able to process all the 1211 messages specified in [F3411]. Sending them within the DRIP Wrapper 1212 makes them opaque to receivers lacking support for DRIP 1213 authentication messages. Thus messages within a Wrapper are sent 1214 twice: in the clear, and authenticated within the Wrapper. The DRIP 1215 Manifest format would seem to be a more efficient use of the 1216 transport channel. 1218 The DRIP Wrapper has a specific use case for DRIP aware receivers. 1219 For receiver plotting received Location Messages (Message Type 0x2) 1220 on a map display an embedded Location Message in a DRIP Wrapper can 1221 be colored differently to signify trust in the Location data - be it 1222 current or previous Location reports that are wrapped. 1224 7. ICAO Considerations 1226 DRIP requests the following SAM Type's to be allocated: 1228 1. DRIP Link 1230 2. DRIP Wrapper 1232 3. DRIP Manifest 1234 4. DRIP Frame 1236 8. IANA Considerations 1238 8.1. Update IANA DRIP Registry 1240 This document requests a new subregistry for Frame Type. 1242 DRIP Frame Type: This 8-bit valued subregistry is for Frame Types to 1243 be later allocated. Future additions to this subregistry are to 1244 be made through Expert Review (Section 4.5 of [RFC8126]). The 1245 following values are defined: 1247 +============+==============+==================+ 1248 | Frame Type | Name | Description | 1249 +============+==============+==================+ 1250 | 0x00 | Reserved | Reserved | 1251 +------------+--------------+------------------+ 1252 | 0xC0-0xFF | Experimental | Experimental Use | 1253 +------------+--------------+------------------+ 1255 Table 4 1257 9. Security Considerations 1259 9.1. Manifest Hash Length 1261 For DRIP Manifest an 12-byte hash length has been selected by the 1262 authors for a number of reasons. 1264 1. Hash lengths smaller than 8-bytes (for example 4-bytes) were 1265 originally contemplated but ruled out by comments by various 1266 cryptographers. The main concern raised in this forum was that 1267 the length of hash would not provide strong resistance against 1268 collision rate. The authors also after further review agreed 1269 with this and also realized operationally it was not necessarily 1270 viable. While 4-byte hashes would allow more messages to be 1271 filled into a single DRIP Manifest payload (up to 22 individual 1272 hashes) the length of time for the UA to stay in a single place 1273 where the Observer would receive all the originally messages to 1274 rehash to verify such a message was impractical. 1276 2. Hash lengths larger than 8-bytes (for example 12 or 16-bytes) 1277 were also considered by the authors. These got the approval of 1278 the cryptographers but the number of hashes to send became much 1279 lower (only 5 individual hashes). While this lower number is a 1280 more reasonable number of original messages the Observer would 1281 have to capture it would also mean that potentially more DRIP 1282 Manifests would need to be sent. Overall the increase length of 1283 the hash did not operationally justify the cost. 1285 3. Simplifying the current design and locking it into using the same 1286 hash as the HHIT instead of allowing for agility in either hash 1287 algorithm or length seemed more realistic to the authors today. 1289 9.2. Replay Attacks 1291 The astute reader may note that the DRIP Link messages, which are 1292 recommended to be sent, are static in nature and contain various 1293 timestamps. These Attestation Link messages can easily be replayed 1294 by an attacker who has copied them from previous broadcasts. There 1295 are two things to mitigate this in DRIP: 1297 1. If an attacker (who is smart and spoofs more than just the UAS 1298 ID/data payloads) willing replays an Attestation Link message 1299 they have in principle actually helped by ensuring the message is 1300 sent more frequently and be received by potential Observers. 1302 2. It is RECOMMENDED to send more than just DRIP Link messages, 1303 specifically those that sign over changing data using the current 1304 session keypair, and those messages are sent more frequently. An 1305 UA beaconing these messages then actually signing other messages 1306 using the keypair validates the data receiver by an Observer. An 1307 UA who does not either run DRIP themselves or does not have 1308 possession of the same private key, would be clearly exposed upon 1309 signature verification. 1311 9.3. Trust Timestamp Offsets 1313 Note the discussion of Trust Timestamp Offsets here is in context of 1314 the DRIP Wrapper (Section 5.3) and DRIP Manifest (Section 5.4) 1315 messages. For DRIP Link (Section 5.2) messages these offsets are set 1316 by the Attestor (typically a registry) and have their own set of 1317 considerations as seen in [drip-registries]. 1319 The offset of the Trust Timestamp (defined as a very short Expiration 1320 Timestamp) is one that needs careful consideration for any 1321 implementation. The offset should be shorter than any given flight 1322 duration (typically less than an hour) but be long enough to be 1323 received and processed by Observers (larger than a few seconds). It 1324 recommended that 3-5 minutes should be sufficient to serve this 1325 purpose in any scenario, but is not limited by design. 1327 10. Acknowledgments 1329 Ryan Quigley and James Mussi of AX Enterprize, LLC for early 1330 prototyping to find holes in the draft specifications. 1332 Soren Friis for pointing out that Wi-Fi implementations would not 1333 always give access to the MAC Address, originally used in calculation 1334 of the hashes for DRIP Manifest. Also, for confirming that Message 1335 Packs (0xF) can only carry up to 9 ASTM frames worth of data (9 1336 Authentication pages) - this drove the requirement for max page 1337 length of Authentication Data itself. 1339 11. References 1341 11.1. Normative References 1343 [F3411] "Standard Specification for Remote ID and Tracking", 1344 February 2020. 1346 [NIST.SP.800-185] 1347 Kelsey, J., Change, S., and R. Perlner, "SHA-3 Derived 1348 Functions: cSHAKE, KMAC, TupleHash and ParallelHash", NIST 1349 Special Publication SP 800-185, 1350 DOI 10.6028/nist.sp.800-185, December 2016, 1351 . 1354 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1355 Requirement Levels", BCP 14, RFC 2119, 1356 DOI 10.17487/RFC2119, March 1997, 1357 . 1359 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1360 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1361 May 2017, . 1363 11.2. Informative References 1365 [drip-registries] 1366 Wiethuechter, A., Card, S., and R. Moskowitz, "DRIP 1367 Registries", Work in Progress, Internet-Draft, draft- 1368 wiethuechter-drip-registries-01, 22 October 2021, 1369 . 1372 [drip-requirements] 1373 Card, S., Ed., Wiethuechter, A., Moskowitz, R., and A. 1374 Gurtov, "Drone Remote Identification Protocol (DRIP) 1375 Requirements and Terminology", RFC 9153, 1376 DOI 10.17487/RFC9153, February 2022, 1377 . 1379 [drip-rid] Moskowitz, R., Card, S. W., Wiethuechter, A., and A. 1380 Gurtov, "UAS Remote ID", Work in Progress, Internet-Draft, 1381 draft-ietf-drip-uas-rid-01, 9 September 2020, 1382 . 1385 [faa-rid] United States Federal Aviation Administration (FAA), 1386 "Remote Identification of Unmanned Aircraft", 2021, 1387 . 1390 Appendix A. Authentication State Diagrams & Color Scheme 1392 ASTM Authentication has only 3 states: None, Invalid or Valid. This 1393 is because under ASTM the idea is that Authentication is done by an 1394 external service hosted somewhere on the Internet so it is assumed 1395 you will always get some sort of answer back. With DRIP this 1396 classification becomes more complex with the support of "offline" 1397 scenarios where the receiver does not have Internet connectivity. 1398 With the use of asymmetric keys this means the public key (PK) must 1399 somehow be obtained - [drip-registries] gets more into detail how 1400 these keys are stored on DNS and one reason for DRIP Authentication 1401 is to send PK's over Broadcast RID. 1403 There are two keys of interest: the PK of the UA and the PK of the 1404 HDA (or Registry). This document gives a clear way to send the PK of 1405 the UA over the Broadcast RID messages - however the PK of the 1406 Registry is not. It can be using the same mechanism but is not 1407 required to do so due to potential operational constraints and 1408 implementation of a given UA transmitter. As such there are 1409 scenarios where you may have part of the key-chain but not all of it. 1411 The intent of this appendix is to give some kind of recommended way 1412 to classify these various states and convey it to the user through 1413 colors and state names/text. 1415 A.1. State Table 1417 The table below lays out the RECOMMENDED colors to associate with 1418 state. 1420 +==============+========+===================================+ 1421 | State | Color | Details | 1422 +==============+========+===================================+ 1423 | None | Black | No Authentication being received | 1424 +--------------+--------+-----------------------------------+ 1425 | Partial | Gray | Authentication being received but | 1426 | | | missing pages | 1427 +--------------+--------+-----------------------------------+ 1428 | Unsupported | Brown | Authentication Type/SAM Type of | 1429 | | | received message not supported | 1430 +--------------+--------+-----------------------------------+ 1431 | Unverifiable | Yellow | Data needed for verification | 1432 | | | missing | 1433 +--------------+--------+-----------------------------------+ 1434 | Verified | Green | Valid verification results | 1435 +--------------+--------+-----------------------------------+ 1436 | Trusted | Blue | Valid verification results and | 1437 | | | HDA is marked as trusted | 1438 +--------------+--------+-----------------------------------+ 1439 | Questionable | Orange | Inconsistent verification results | 1440 +--------------+--------+-----------------------------------+ 1441 | Unverified | Red | Invalid verification results | 1442 +--------------+--------+-----------------------------------+ 1443 | Conflicting | Purple | Inconsistent verification results | 1444 | | | and HDA is marked as trusted | 1445 +--------------+--------+-----------------------------------+ 1447 Table 5 1449 A.2. State Diagrams 1451 This section gives some RECOMMENDED state flows that DRIP should 1452 follow. 1454 A.2.1. Notations 1455 o--------------o 1456 | PROCESS | 1457 o--------------o 1459 +--------------+ 1460 | STATE | 1461 +--------------+ 1463 ooooo 1464 o N o Transition N 1465 ooooo 1467 +-----> Transition Option False/No 1469 -----> Transition Option True/Yes 1471 Figure 11: Diagram Notations 1473 A.2.2. General 1475 o---------------------o ooooo +------+ 1476 | Start |---->o 1 o+----->| None | 1477 o---------------------o ooooo +------+ 1478 | 1479 v 1480 ooooo +-------------+ 1481 o 2 o+----->| Unsupported | 1482 ooooo +-------------+ 1483 | ^ 1484 v | 1485 +---------+ ooooo | 1486 | Partial |<-----+o 3 o | 1487 +---------+ ooooo | 1488 | | 1489 v + 1490 ooooo ooooo o-------------o 1491 o 4 o------>o 5 o------>| SAM Decoder | 1492 ooooo ooooo o-------------o 1493 + 1494 | 1495 v 1496 o------------------o 1497 | AuthType Decoder | 1498 o------------------o 1500 Figure 12: Standard Authentication Colors/State 1502 +============+=============================+======================+ 1503 | Transition | Transition Query | Next State/Process/ | 1504 | | | Transition (Yes, No) | 1505 +============+=============================+======================+ 1506 | 1 | Receiving Authentication | 2, None | 1507 | | Pages? | | 1508 +------------+-----------------------------+----------------------+ 1509 | 2 | Authentication Type | 3, Unsupported | 1510 | | Supported? | | 1511 +------------+-----------------------------+----------------------+ 1512 | 3 | All Pages of Authentication | 4, Partial | 1513 | | Message Received? | | 1514 +------------+-----------------------------+----------------------+ 1515 | 4 | Is Authentication Type | 5, AuthType Decoder | 1516 | | received 5? | | 1517 +------------+-----------------------------+----------------------+ 1518 | 5 | Is SAM Type Supported? | SAM Decoder, | 1519 | | | Unsupported | 1520 +------------+-----------------------------+----------------------+ 1522 Table 6 1524 A.2.3. DRIP SAM 1526 o-------------o ooooo o-----------------------------o 1527 | SAM Decoder |---->o 6 o------>| DRIP Wrapper/Manifest/Frame | 1528 o-------------o ooooo o-----------------------------o 1529 + | ^ 1530 | | | 1531 v v | 1532 o-----------o o--------------------o | 1533 | DRIP Link |--->| Update State Cache | | 1534 o-----------o o--------------------o | 1535 | | 1536 v | 1537 o--------------o ooooo o----------------------o 1538 | NOP / Return |<------+o 7 o----->| Extract Message from | 1539 o--------------o ooooo | Verification Queue | 1540 o----------------------o 1542 Figure 13: DRIP SAM Decoder 1544 +============+=====================+========================+ 1545 | Transition | Transition Query | Next State/Process/ | 1546 | | | Transition (Yes, No) | 1547 +============+=====================+========================+ 1548 | 6 | Is SAM Type DRIP | DRIP Link, DRIP | 1549 | | Link? | Wrapper/Manifest/Frame | 1550 +------------+---------------------+------------------------+ 1551 | 7 | Messages in | Extract Message from | 1552 | | Verification Queue? | Verification Queue, | 1553 | | | NOP / Return | 1554 +------------+---------------------+------------------------+ 1556 Table 7 1558 A.2.4. DRIP Link 1560 o-----------o ooooo ooooo +--------------+ 1561 | DRIP Link |----->o 8 o+----->o 9 o+----->| Unverifiable | 1562 o-----------o ooooo ooooo +--------------+ 1563 | | 1564 |-------------' 1565 v 1566 ooooo +------------+ 1567 o 10 o+----->| Unverified | 1568 ooooo +------------+ 1569 | 1570 v 1571 o---------------------o 1572 | Add UA DET/PK | 1573 | to Key Cache | 1574 o---------------------o 1575 | 1576 v 1577 ooooo +----------+ 1578 o 11 o+------>| Verified | 1579 ooooo +----------+ 1580 | ^ 1581 v | 1582 o-------------------------o 1583 | Mark UA DET/PK | 1584 | as Trusted in Key Cache | 1585 o-------------------------o 1587 Figure 14: DRIP Link State Decoder 1589 +============+==========================+===========================+ 1590 | Transition | Transition Query | Next State/Process/ | 1591 | | | Transition (Yes, No) | 1592 +============+==========================+===========================+ 1593 | 8 | Registry DET/PK in Key | 10, 9 | 1594 | | Cache? | | 1595 +------------+--------------------------+---------------------------+ 1596 | 9 | Registry PK found | 10, Unverifiable | 1597 | | Online? | | 1598 +------------+--------------------------+---------------------------+ 1599 | 10 | Registry Signature | Add UA DET/PK to Key | 1600 | | Verified? | Cache, Unverified | 1601 +------------+--------------------------+---------------------------+ 1602 | 11 | Registry DET/PK marked | Mark UA DET/PK as | 1603 | | as Trusted in Key Cache? | Trusted in Key | 1604 | | | Cache, Verified | 1605 +------------+--------------------------+---------------------------+ 1607 Table 8 1609 A.2.5. DRIP Wrapper/Manifest/Frame 1610 o-----------------------------o +--------------+ 1611 | DRIP Wrapper/Manifest/Frame | | Unverifiable | 1612 o-----------------------------o +--------------+ 1613 | ^ 1614 v | 1615 ooooo ooooo o--------------------o 1616 o 12 o+----->o 13 o+----->| Add Message to | 1617 ooooo ooooo | Verification Queue | 1618 | | o--------------------o 1619 | | 1620 |-------------' 1621 v 1622 ooooo ooooo ooooo +------------+ 1623 o 14 o+----->o 15 o+----->o 16 o+----->| Unverified | 1624 ooooo ooooo ooooo +------------+ 1625 | | | 1626 v v | 1627 ooooo +-------------+ | 1628 o 17 o+----->| Conflicting | | 1629 ooooo +-------------+ | 1630 | | 1631 v v 1632 ooooo +--------------+ 1633 o 18 o---------------->| Questionable | 1634 ooooo +--------------+ 1635 + 1636 | 1637 v 1638 ooooo +----------+ 1639 o 19 o+----->| Verified | 1640 ooooo +----------+ 1641 | 1642 v 1643 +---------+ 1644 | Trusted | 1645 +---------+ 1647 Figure 15: DRIP Wrapper/Manifest/Frame State Decoder 1649 +============+==============================+======================+ 1650 | Transition | Transition Query | Next State/Process/ | 1651 | | | Transition (Yes, No) | 1652 +============+==============================+======================+ 1653 | 12 | UA DET/PK in Key Cache? | 14, 13 | 1654 +------------+------------------------------+----------------------+ 1655 | 13 | UA PK found Online? | 14, Add Message to | 1656 | | | Verification Queue | 1657 +------------+------------------------------+----------------------+ 1658 | 14 | UA Signature Verified? | 17, 15 | 1659 +------------+------------------------------+----------------------+ 1660 | 15 | Has past Messages of this | Conflicting, 16 | 1661 | | type been marked as Trusted? | | 1662 +------------+------------------------------+----------------------+ 1663 | 16 | Has past Messages of this | Questionable, | 1664 | | type been marked as | Unverified | 1665 | | Questionable or Verified? | | 1666 +------------+------------------------------+----------------------+ 1667 | 17 | Has past Messages of this | Conflicting, 18 | 1668 | | type been marked as | | 1669 | | Conflicting? | | 1670 +------------+------------------------------+----------------------+ 1671 | 18 | Has past Messages of this | Questionable, 19 | 1672 | | type been marked as | | 1673 | | Questionable or Unverified? | | 1674 +------------+------------------------------+----------------------+ 1675 | 19 | Is UA DET/PK marked as | Trusted, Verified | 1676 | | Trusted in Key Cache? | | 1677 +------------+------------------------------+----------------------+ 1679 Table 9 1681 Appendix B. HDA-UA Broadcast Attestation 1683 0 1 2 3 1684 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1685 +---------------+---------------+---------------+---------------+ 1686 | | 1687 | DRIP | 1688 | Entity Tag of HDA | 1689 | | 1690 +---------------+---------------+---------------+---------------+ 1691 | | 1692 | DRIP | 1693 | Entity Tag of UA | 1694 | | 1695 +---------------+---------------+---------------+---------------+ 1696 | | 1697 | | 1698 | | 1699 | Host Identity of UA | 1700 | | 1701 | | 1702 | | 1703 | | 1704 +---------------+---------------+---------------+---------------+ 1705 | Not Before Timestamp by HDA | 1706 +---------------+---------------+---------------+---------------+ 1707 | Not After Timestamp by HDA | 1708 +---------------+---------------+---------------+---------------+ 1709 | | 1710 | | 1711 | | 1712 | | 1713 | | 1714 | | 1715 | | 1716 | Signature by HDA | 1717 | | 1718 | | 1719 | | 1720 | | 1721 | | 1722 | | 1723 | | 1724 | | 1725 +---------------+---------------+---------------+---------------+ 1727 DRIP Entity Tag of HDA: (16-bytes) 1728 DET of HDA. 1730 DRIP Entity Tag of UA: (16-bytes) 1731 DET of UA. 1733 Host Identity of UA: (32-bytes) 1734 HI of UA 1736 Expiration Timestamp by HDA (4 bytes): 1737 Timestamp denoting recommended time to trust data to. 1739 Signing Timestamp by HDA (4 bytes): 1740 Current time at signing. 1742 HDA Signature (64 bytes): 1743 Signature over preceding fields using the keypair of 1744 the HDA. 1746 Figure 16: Example DRIP HDA-UA Broadcast Attestation 1748 Appendix C. Example TX/RX Flow 1750 In this example the UA is sending all DRIP Authentication Message 1751 formats (DRIP Link, DRIP Wrapper and DRIP Manifest) during flight, 1752 along with standard ASTM Messages. The objective is to show the 1753 combinations of messages that must be received to properly validate a 1754 DRIP equipped UA and examples of their various states (Appendix A). 1756 +-------------------+ 1757 .-----| Unmanned Aircraft |-----. 1758 | +-------------------+ | 1759 | 1 | 2 | 3 | 4 1760 | | | | 1762 O O O O 1763 --|-- --|-- --|-- --|-- 1764 / \ / \ / \ / \ 1765 A B C D 1767 Broadcast Paths: Messages Received 1768 1: DRIP Link 1769 2: DRIP Link and DRIP Wrapper or DRIP Manifest 1770 3: DRIP Wrapper or DRIP Manifest 1771 4: None 1773 Observers: Authentication State 1774 A: Unverifiable 1775 B: Verified, Trusted, Unverified, Questionable, or Conflicting 1776 C: Unverifiable 1777 D: None 1779 As the above example shows to properly authenticate both a DRIP Link 1780 and a DRIP Wrapper or DRIP Manifest are required. 1782 Authors' Addresses 1784 Adam Wiethuechter 1785 AX Enterprize, LLC 1786 4947 Commercial Drive 1787 Yorkville, NY 13495 1788 United States of America 1789 Email: adam.wiethuechter@axenterprize.com 1790 Stuart Card 1791 AX Enterprize, LLC 1792 4947 Commercial Drive 1793 Yorkville, NY 13495 1794 United States of America 1795 Email: stu.card@axenterprize.com 1797 Robert Moskowitz 1798 HTT Consulting 1799 Oak Park, MI 48237 1800 United States of America 1801 Email: rgm@labs.htt-consult.com