idnits 2.17.1 draft-wiethuechter-drip-auth-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (27 July 2020) is 1368 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) -- Looks like a reference, but probably isn't: '1' on line 277 -- Looks like a reference, but probably isn't: '0' on line 277 == Missing Reference: '1-4' is mentioned on line 482, but not defined == Missing Reference: '129-132' is mentioned on line 481, but not defined == Missing Reference: '0xF' is mentioned on line 518, but not defined == Missing Reference: '0x2' is mentioned on line 519, but not defined -- Looks like a reference, but probably isn't: '133' on line 509 -- Looks like a reference, but probably isn't: '5' on line 510 -- Looks like a reference, but probably isn't: '132' on line 567 -- Looks like a reference, but probably isn't: '6' on line 568 -- Looks like a reference, but probably isn't: '135' on line 604 -- Looks like a reference, but probably isn't: '7' on line 605 -- Looks like a reference, but probably isn't: '144' on line 747 -- Looks like a reference, but probably isn't: '16' on line 748 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DRIP A. Wiethuechter 3 Internet-Draft S. Card 4 Intended status: Standards Track AX Enterprize 5 Expires: 28 January 2021 R. Moskowitz 6 HTT Consulting 7 27 July 2020 9 DRIP Authentication Formats 10 draft-wiethuechter-drip-auth-03 12 Abstract 14 This document describes how to include trust into the ASTM Remote ID 15 specification defined in ASTM 3411-19 under a Broadcast Remote ID 16 (RID) scenario. It defines a few different message schemes (based on 17 the Authentication Message) that can be used to assure past messages 18 sent by a UA and also act as an assurance for UA trustworthiness in 19 the absence of Internet connectivity at the receiving node. 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 28 January 2021. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. DRIP Requirements Addressed . . . . . . . . . . . . . . . 3 56 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 58 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Problem Space And Document Focus . . . . . . . . . . . . 4 61 3.2. ASTM Authentication Message . . . . . . . . . . . . . . . 4 62 4. DRIP Authentication Framing Formats . . . . . . . . . . . . . 5 63 4.1. DRIP Authentication Frame . . . . . . . . . . . . . . . . 6 64 4.1.1. DRIP Header . . . . . . . . . . . . . . . . . . . . . 7 65 4.1.2. DRIP Authentication Data . . . . . . . . . . . . . . 8 66 4.1.3. Forward Error Correction . . . . . . . . . . . . . . 8 67 4.2. DRIP Wrapper Frame . . . . . . . . . . . . . . . . . . . 8 68 4.2.1. UA Hierarchical Host Identity Tag . . . . . . . . . . 9 69 4.2.2. Trust Timestamp . . . . . . . . . . . . . . . . . . . 10 70 4.2.3. Authentication Data . . . . . . . . . . . . . . . . . 10 71 4.2.4. Signature . . . . . . . . . . . . . . . . . . . . . . 10 72 5. Bluetooth 4.X Formats . . . . . . . . . . . . . . . . . . . . 10 73 5.1. [1-4] Wrapped ASTM Message(s) . . . . . . . . . . . . . . 11 74 5.2. 5 Wrapped ASTM Message(s) . . . . . . . . . . . . . . . . 11 75 5.3. Manifest . . . . . . . . . . . . . . . . . . . . . . . . 12 76 5.3.1. Hash Algorithm And Operation . . . . . . . . . . . . 12 77 5.3.2. 4 Byte Manifest . . . . . . . . . . . . . . . . . . . 12 78 5.3.3. 8 Byte Manifest . . . . . . . . . . . . . . . . . . . 13 79 5.3.4. Pseudo-blockchain Hashes . . . . . . . . . . . . . . 14 80 5.3.5. Limitations . . . . . . . . . . . . . . . . . . . . . 15 81 5.4. Certificate . . . . . . . . . . . . . . . . . . . . . . . 15 82 5.5. Recommendations . . . . . . . . . . . . . . . . . . . . . 16 83 6. Bluetooth 5 Formats . . . . . . . . . . . . . . . . . . . . . 16 84 6.1. Certificate . . . . . . . . . . . . . . . . . . . . . . . 17 85 6.2. Message Pack Signature . . . . . . . . . . . . . . . . . 17 86 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 7.1. 2 Wrapped ASTM Messages . . . . . . . . . . . . . . . . . 18 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 89 9. ASTM Considerations . . . . . . . . . . . . . . . . . . . . . 21 90 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 92 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 93 11.2. Informative References . . . . . . . . . . . . . . . . . 21 94 Appendix A. Thoughts on ASTM Authentication Message . . . . . . 22 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 97 1. Introduction 99 UA Systems (UAS) are usually in a volatile environment when it comes 100 to communication. UA are generally small with little computational 101 (or flying) horsepower to carry standard communication equipment. 102 This limits the mediums of communication to few viable options. 104 Observer systems (e.g. smartphones and tablets) place further 105 constraints on the communication options. The Remote ID Broadcast 106 messages MUST be available to applications on these platforms without 107 modifying the devices. 109 The ASTM standard [F3411-19] focuses on two ways of communicating to 110 a UAS for RID: Broadcast and Network. 112 This document will focus on adding trust to Broadcast RID in the 113 Authentication Message format. 115 1.1. DRIP Requirements Addressed 117 The following [drip-requirements] will be addressed: 119 GEN 1: Provable Ownership 120 This will be addressed using the Certificate Message types 121 (Section 5.4, Section 6.1). 123 GEN 2: Provable Binding 124 This will be addressed using the Wrapped ASTM Message, Manifest 125 Message and Message Pack Signature types (Section 4.2, 126 Section 5.3, Section 6.2). 128 GEN 3: Provable Registration 129 This will be addressed using the Certificate Message types 130 (Section 5.4, Section 6.1). 132 2. Terms and Definitions 134 2.1. Requirements Terminology 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 138 "OPTIONAL" in this document are to be interpreted as described in BCP 139 14 [RFC2119] [RFC8174] when, and only when, they appear in all 140 capitals, as shown here. 142 2.2. Definitions 144 See [drip-requirements] for common DRIP terms. 146 Aircraft 147 In this document whenever the word Aircraft is used it is refering 148 to an Unmanned Aircraft (UA) not a Manned Aircraft. 150 HI 151 Host Identity. The public key portion of an asymmetric keypair 152 from HIP. In this document it is assumed that the HI is based on 153 a EdDSA25519 keypair. This is supported by new crypto defined in 154 [new-hip-crypto]. 156 HIT 157 Host Identity Tag. A 128 bit handle on the HI. Defined in HIPv2 158 [RFC7401]. 160 HHIT 161 Hierarchical Host Identity Tag. A 128 bit handle on the HI contain 162 extra information not found in a standard HIT. Defined in 163 [hierarchical-hit]. 165 3. Background 167 3.1. Problem Space And Document Focus 169 The current standard for Remote ID (RID) does not, in any meaningful 170 capacity, address the concerns of trust in the UA space with 171 communication in the Broadcast RID environment. This is a 172 requirement that will need to be addressed eventually for various 173 different parties that have a stake in the UA industry. 175 The following subsections will provide a high level reference to the 176 ASTM standard for Authentication Messages and how their current 177 limitations effect trust in the Broadcast RID environment. 179 3.2. ASTM Authentication Message 180 Page 0: 181 0 1 2 3 182 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 183 +---------------+-----------------------------------------------+ 184 | Auth Header | | 185 +---------------+ ASTM Authentication Headers +---------------+ 186 | | | 187 +-----------------------------------------------+ | 188 | | 189 | Authentication Data / Signature | 190 | | 191 | | 192 +---------------------------------------------------------------+ 194 Page 1 - 4: 195 0 1 2 3 196 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 197 +---------------+-----------------------------------------------+ 198 | Auth Header | | 199 +---------------+ | 200 | | 201 | Authentication Data / Signature | 202 | | 203 | | 204 | | 205 +---------------------------------------------------------------+ 207 Auth Header (1 byte): 208 Contains Authentication Type and Page Number. For 209 DRIP Authentication this is a value of 0xD. 211 ASTM Authentication Headers: (6 bytes) 212 Contains other header information for the Authentication 213 Message from ASTM UAS RID Standard. 215 Authentication Data / Signature: (109 bytes: 17+23*4) 216 Opaque authentication data. 218 The above diagram is the format defined by ASTM that is the frame 219 which everything this document fits into. The specific details of 220 the ASTM headers are abstracted away as they are not necessarily 221 required for this document. 223 4. DRIP Authentication Framing Formats 225 Currently the ASTM AuthType of 0xD should be used to denote DRIP 226 based Authentication. The max page count of the Authentication 227 Message is also 10, instead of 5. 229 4.1. DRIP Authentication Frame 231 Page 0: 232 0 1 2 3 233 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 234 +---------------+-----------------------------------------------+ 235 | Auth Header | | 236 +---------------+ ASTM Authentication Headers +---------------+ 237 | | DRIP Header | 238 +-----------------------------------------------+---------------+ 239 | | 240 | DRIP Authentication Data | 241 | | 242 | | 243 +---------------------------------------------------------------+ 245 Page 1 - Page N-1: 246 0 1 2 3 247 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 248 +---------------+-----------------------------------------------+ 249 | Auth Header | | 250 +---------------+ | 251 | | 252 | DRIP Authentication Data | 253 | | 254 | | 255 | | 256 +---------------------------------------------------------------+ 258 Page N: 259 0 1 2 3 260 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 261 +---------------+-----------------------------------------------+ 262 | Auth Header | | 263 +---------------+ | 264 | | 265 | Forward Error Correction | 266 | | 267 | | 268 | | 269 +---------------------------------------------------------------+ 271 DRIP Header (1 byte): 272 7 6 5 4 3 2 1 0 273 +-----+-----+-----+-----+-----+-----+-----+-----+ 274 | FEC | DRIP AuthType | 275 +-----+-----+-----+-----+-----+-----+-----+-----+ 276 FEC (1 bit): 277 Enabled [1] or Disabled [0]. Signals if Page N is 278 filled with Reed Solomon FEC. 280 DRIP AuthType (7 bits): 281 DRIP AuthType Values 282 ------------- ------ 283 0 Wrapped ASTM Message(s) 0 284 1 Wrapped ASTM Message(s) 1 285 2 Wrapped ASTM Message(s) 2 286 3 Wrapped ASTM Message(s) 3 287 4 Wrapped ASTM Message(s) 4 288 5 Wrapped ASTM Message(s) 5 289 8 Byte Manifest 6 290 4 Byte Manifest 7 291 Reserved (Wrapped Messages) 8-15 292 Certificate: Registry on Aircraft 16 293 Reserved (Certificates) 17-31 294 Private Use 32-63 295 Reserved 64-111 296 Experimental Use 112-127 298 DRIP Authentication Data (223 bytes): 299 DRIP Authentication data. 0 to 223 bytes. 301 Forward Error Correction (23 bytes): 302 Optional and signaled using DRIP Header. Always last 303 Authentication page. Reed Solomon across preceding pages. 305 4.1.1. DRIP Header 307 The DRIP Header is used to signal what kind of Authentication under 308 DRIP that the message is using and consists of two fields. 310 The Most Significant Bit is used to signal if FEC is present in the 311 final page of the Authentication Message. It MUST be set to 1 if FEC 312 is being used. 314 The lower 7 bits are used as the DRIP AuthType field denoting what 315 Authentication type is being used. There are 5 major areas carved 316 out of the DRIP AuthType defined by the following bitmaps: 318 000 xxxx (0x00-0x0F): Wrapped Messages (16) 319 001 xxxx (0x10-0x1F): Certificates (16) 320 01x xxxx (0x20-0x3F): Private Use (32) 321 1xx xxxx (0x40-0x6F): Reserved (48) 322 111 xxxx (0x70-0x7F): Experimental Use (16) 324 4.1.2. DRIP Authentication Data 326 This field has a maximum size of 223 bytes. If the data is less than 327 223 bytes and a page is only partially filled then the rest of the 328 partially filled page must be null padded. 330 4.1.3. Forward Error Correction 332 To help Bluetooth (specifically Bluetooth 4) achieve the goal of 333 reliable receipt of paged messages a Forward Error Correction (FEC) 334 scheme is introduced and SHOULD be used for Bluetooth 4 and SHOULD 335 NOT be used for Bluetooth 5 under DRIP. 337 Due to the nature of Bluetooth 4 and the existing ASTM paging 338 structure an optimization can be used. If a Bluetooth frame fails 339 its CRC check, then the frame is dropped without notification to the 340 upper protocol layers. From the Remote ID perspective this means the 341 loss of a complete frame/message/page. In Authentication Messages, 342 each page is already numbered so the loss of a page allows the 343 receiving application to build a "dummy" page filled with nulls 344 (other than the ASTM Header and Auth Header which is known). 346 A compliant implementation of this standard MUST use Reed Solomon for 347 the FEC. With this the entire authentication message (all pages, 348 including headers) are used to generate 23 bytes of parity. This 349 parity is appended in one full page (always the last) allowing for 350 recovery when any single page is lost in transmission. 352 If more than one page is lost (>1/5 for 5 page messages, >1/10 for 10 353 page messages) than the error rate of the link is already beyond 354 saving and the application has more issues to deal with. 356 4.2. DRIP Wrapper Frame 358 0 1 2 3 359 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 360 +---------------+---------------+---------------+---------------+ 361 | | 362 | UA Hierarchical | 363 | Host Identity Tag | 364 | | 365 +---------------+---------------+---------------+---------------+ 366 | Trust Timestamp | 367 +---------------+---------------+---------------+---------------+ 368 | | 369 . . 370 . Authentication Data . 371 . . 373 | | 374 +---------------+---------------+---------------+---------------+ 375 | | 376 | | 377 | | 378 | | 379 | | 380 | | 381 | | 382 | Signature | 383 | | 384 | | 385 | | 386 | | 387 | | 388 | | 389 | | 390 | | 391 +---------------+---------------+---------------+---------------+ 393 UA Hierarchial Host Identity Tag (16 bytes): 394 The UAs HHIT in byte form. Hashed from the EdDSA25519 395 public key. 397 Trust Timestamp (4 bytes): 398 Timestamp denoting current time plus an offset to trust 399 message to. 401 Authentication Data (116/139 bytes): 402 Opaque authentication data using DRIP format specified in 403 the DRIP Header. 0 to 116 bytes when FEC bit is 1, 0 to 404 139 bytes when FEC bit is 0. 406 Signature (64 bytes): 407 Signature over preceding fields using the EdDSA25519 408 keypair. 410 This framing resides within the General Frame's DRIP Authentication 411 Data (Section 4.1.2). 413 4.2.1. UA Hierarchical Host Identity Tag 415 To avoid needing the UAs HHIT via the ASTM Basic ID in a detached 416 fashion the 16 byte HHIT of the UA is included in the wrapper frame. 418 The HHIT for the UA (and other entities in the RID and greater UTM 419 system under DRIP) is an enhancement of the Host Identity Tag (HIT) 420 of HIPv2 [RFC7401] introducing hierarchy as defined in HHIT 421 [hierarchical-hit]. 423 Using Hierarchical HITs for UAS RID is outlined in HHIT based UAS RID 424 [drip-uas-rid]. 426 4.2.2. Trust Timestamp 428 Trust Timestamp MUST be current UNIX time plus an offset into the 429 future. To avoid replay attacks the Trust Timestamp field must be 430 well founded. 432 When wrapping a Vector (Position) Message the payload WILL contain 433 (by ASTM rules) constantly changing data, this includes its own 434 timestamp. This timestamp is only 2 bytes, which is easily attacked 435 and only expresses the 1/10th of seconds since the last hour. 437 Other ASTM message types, such as Basic ID and Self-ID are static 438 messages with no changing data. To protect a replay of these signed 439 messages the Trust Timestamp is the field during signing to be 440 guaranteed to change. 442 The offset used against the UNIX timestamp is not defined in this 443 document. Best practices to identify a acceptable offset should be 444 used taking into consideration the UA environment, and propagation 445 characteristics of the messages being sent. 447 4.2.3. Authentication Data 449 This field has a maximum of 116 bytes in length when the FEC bit of 450 the DRIP Header is turned on and 139 bytes of maximum length when 451 turned off. 453 4.2.4. Signature 455 The wrapper signature is generated using the private key half of the 456 the UAs Host Identity (HI) and is done over all preceding data. 457 ASTM/DRIP Headers are exclude from this operation only information 458 within the DRIP Wrapper Frame is signed. 460 5. Bluetooth 4.X Formats 462 With Bluetooth 4.X formatting the goal is to attempt to bring 463 reliable receipt of paged messages. 465 Unless otherwise specified the FEC Bit of the DRIP Header MUST be set 466 to 1 when using Bluetooth 4 to take advantage of FEC for lost frames. 468 5.1. [1-4] Wrapped ASTM Message(s) 470 0 1 2 3 471 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 472 +---------------+---------------+---------------+---------------+ 473 | | 474 . . 475 . ASTM Message: Type 0-1, 3-5 (1 to 4) . 476 . . 477 | | 478 +---------------+---------------+---------------+---------------+ 480 DRIP Header: 481 With FEC: 0x81-0x84 [129-132] (RECOMMENDED) 482 Without FEC: 0x01-0x04 [1-4] 484 ASTM Message: Type 0-1, 3-5 (25 bytes): 485 Valid ASTM Messages of Type 0, 1, 3, 4, or 5. 486 If more than 1 then ASTM Messages in Message Type order. 488 This DRIP Authentication type uses the Wrapper Frame format 489 (Section 4.2), filling the Authentication Data (Section 4.2.3) field 490 with an ASTM Message (all types except Message Pack [0xF] and 491 Authentication [0x2]). 493 When multiple ASTM Messages are being wrapped they MUST be in Message 494 Type order. 496 5.2. 5 Wrapped ASTM Message(s) 498 0 1 2 3 499 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 500 +---------------+---------------+---------------+---------------+ 501 | | 502 . . 503 . ASTM Message: Type 0-1, 3-5 (5) . 504 . . 505 | | 506 +---------------+---------------+---------------+---------------+ 508 DRIP Header: 509 With FEC: 0x85 [133] (RECOMMENDED) 510 Without FEC: 0x05 [5] 512 ASTM Message: Type 0-1, 3-5 (25 bytes): 513 5 valid ASTM Message of Types 0, 1, 3, 4, or 5. 514 ASTM Messages in Message Type order. 516 This DRIP Authentication type uses the Wrapper Frame format 517 (Section 4.2), filling the Authentication Data (Section 4.2.3) field 518 with an ASTM Message (all types except Message Pack [0xF] and 519 Authentication [0x2]). 521 ASTM Messages being wrapped MUST be in Message Type order. 523 5.3. Manifest 525 This DRIP Authentication type uses the Wrapper Frame format 526 (Section 4.2), filling the Authentication Data (Section 4.2.3) field 527 with hashes of previously sent messages. 529 By hashing previously sent messages and signing them we gain trust in 530 UAs previous reports. An observer who has been listening for any 531 length of time can hash received messages and cross check against 532 listed hashes. The signature is signed across the list of hashes. 534 5.3.1. Hash Algorithm And Operation 536 The hash algorithm used for the Manifest Message is the same hash 537 algorithm used in creation of the HHIT that is signing the Manifest. 539 A standard HHIT would be using cSHAKE128 from [NIST.SP.800-185]. 540 With cSHAKE128, the hash is computed as follows: 542 cSHAKE128(MAC|Message, 8*H-Len, "", "RemoteID Auth Hash") 544 The message MAC is prepended to the message, as the MAC is the only 545 information that links UA messages from a specific UA. 547 5.3.2. 4 Byte Manifest 548 0 1 2 3 549 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 550 +---------------+---------------+---------------+---------------+ 551 | Hash of Previous Manifest | 552 +---------------+---------------+---------------+---------------+ 553 | Hash of Current Manifest | 554 +---------------+---------------+---------------+---------------+ 555 | Message Hash 1 | 556 +---------------+---------------+---------------+---------------+ 557 | Message Hash 2 | 558 +---------------+---------------+---------------+---------------+ 559 . . 560 . . 561 . . 562 +---------------+---------------+---------------+---------------+ 563 | Message Hash 27 | 564 +---------------+---------------+---------------+---------------+ 566 DRIP Header: 567 With FEC: 0x86 [132] (RECOMMENDED) 568 Without FEC: 0x06 [6] 570 Hash of Previous Manifest: (4 bytes) 571 A hash of the previously sent Authentication message. 573 Hash of Current Manifest: (4 bytes) 574 A hash of the current Authentication message. 576 Message Hash: (4 bytes) 577 A hash of a previously sent message. 27 max. 579 5.3.3. 8 Byte Manifest 580 0 1 2 3 581 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 582 +---------------+---------------+---------------+---------------+ 583 | Hash of Previous Manifest | 584 | | 585 +---------------+---------------+---------------+---------------+ 586 | Hash of Current Manifest | 587 | | 588 +---------------+---------------+---------------+---------------+ 589 | Message Hash 1 | 590 | | 591 +---------------+---------------+---------------+---------------+ 592 | Message Hash 2 | 593 | | 594 +---------------+---------------+---------------+---------------+ 595 . . 596 . . 597 . . 598 +---------------+---------------+---------------+---------------+ 599 | Message Hash 12 | 600 | | 601 +---------------+---------------+---------------+---------------+ 603 DRIP Header: 604 With FEC: 0x87 [135] (RECOMMENDED) 605 Without FEC: 0x07 [7] 607 Hash of Previous Manifest: (8 bytes) 608 A hash of the previously sent Authentication message. 610 Hash of Current Manifest: (8 bytes) 611 A hash of the current Authentication message. 613 Message Hash: (8 bytes) 614 A hash of a previously sent message. 12 max. 616 5.3.4. Pseudo-blockchain Hashes 618 Two special hashes are included; a previous manifest hash, which 619 links to the previous manifest message, as well as a current manifest 620 hash. This gives a pseudo-blockchain provenance to the manifest 621 message that could be traced back if the observer was present for 622 extended periods of time. 624 In regards to the creation and use of the current manifest hash 625 field: 627 During creation and signing of this message format this field MUST 628 be set to 0. So the signature will be based on this field being 629 0, as well as its own hash. It is an open question of if we 630 compute the hash, then sign or sign then compute. 632 There a few different ways to cycle this message. We can "roll 633 up" the hash of 'current' to 'previous' when needed or to 634 completely recompute the hash. This mostly depends on the 635 previous note. 637 5.3.5. Limitations 639 A potential limitation to this format is dwell time of the UA. If 640 the UA is not sticking to a general area then most likely the 641 Observer will not obtain many (if not all) of the messages in the 642 manifest. Without the original messages received no verification can 643 be done. Examples of such scenarios include delivery or survey UA. 645 5.4. Certificate 647 0 1 2 3 648 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 649 +---------------+---------------+---------------+---------------+ 650 | | 651 . . 652 . Certificate: Registry on Aircraft . 653 . . 654 | | 655 +---------------+---------------+---------------+---------------+ 657 DRIP Header: 658 With FEC: 0x90 [144] (RECOMMENDED) 659 Without FEC: 0x10 [16] 661 Certificate: Registry on Aircraft (200 bytes): 662 A certificate granted by the Registry that asserts the 663 binding of UA to the given Registry. 665 This DRIP Authentication type uses the General Frame format 666 (Section 4.1), filling the DRIP Authentication Data (Section 4.1.2) 667 field with a 200 byte Certificate: Registry on Aircraft. 669 What this grants is the ability to authenticate UA Remote ID when the 670 receiving device of the observer (e.g. a smartphone with a dedicated 671 RID application) has no Internet service (e.g. LTE signal). 673 The Certificate: Registry on Aircraft (Cra) is in practice a binding 674 claim between the Registry and the Aircraft, asserting the 675 relationship between the two entities. Cra signs another 676 certificate, Caa (Certificate: Aircraft on Aircraft), that is created 677 during UA provisioning. 679 Importantly this certificate allows offline signature verification 680 from the UA. This is as the UA HI is included in the certificate. 681 Also included is the HHIT of the Registry to check the local 682 shortlist of Registries that the Observer device trusts (mapping 683 HHITs to HIs). 685 More details about Caa, Cra, other certificates and the provisioning 686 process can be found in [drip-identity-claims]. 688 5.5. Recommendations 690 Under ASTM Bluetooth 4.X rules, transmission of dynamic messages are 691 at least every 1 second while static messages (which is what 692 Authentication is classified under) are sent at least every 3 693 seconds. 695 Under DRIP the Certificate Message MUST be transmitted to properly 696 meet the GEN 1 and GEN 3 requirement. 698 The ASTM Message Wrapper and Manifest both satisfy the GEN 2 699 requirement. At least one MUST be implemented to comply with the GEN 700 2 requirement. 702 A single Manifest can carry at most (using the full 10 page limit and 703 8 byte hashes) 12 unique hashes of previously sent messages (of any 704 type). This results in a total of 22 (12 + 10) frames of Bluetooth 705 data being transmitted over Bluetooth. 707 In comparison the Message Wrapper sends 6 pages (each a single frame) 708 for each wrapped message. For backwards compatibility the 709 implementation should also send the standard ASTM message that was 710 wrapped for non-DRIP compliant receivers to obtain. This method 711 results in 84 total Bluetooth frames (12 + (12 * 6)) sent. 713 The question of which is better suited is up to the implementation. 715 6. Bluetooth 5 Formats 717 Under ASTM specification, Bluetooth 5 transport of Remote ID is to 718 use the Message Pack (Type 0xF) format for all transmissions. Under 719 Message Pack all messages are sent together (in Message Type order) 720 in a single Bluetooth frame (up to 250 bytes). Message Packs are 721 required by ASTM to be sent at a rate of 1 per second (like dynamic 722 messages). 724 This gives the benefit of no longer is there any message or page 725 fragmentation in transmission. For this reason the recommended use 726 of FEC such as Reed Solomon using in Bluetooth 4.X is not needed here 727 and is impractical. 729 Any of the Bluetooth 4.X formats can theoretically be used during 730 Bluetooth 5 operation under ASTM, however the following subsections 731 define a number of formats optimized for Message Pack and Bluetooth 732 5. 734 6.1. Certificate 736 0 1 2 3 737 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 738 +---------------+---------------+---------------+---------------+ 739 | | 740 . . 741 . Certificate: Registry on Aircraft . 742 . . 743 | | 744 +---------------+---------------+---------------+---------------+ 746 DRIP Header: 747 With FEC: 0x90 [144] 748 Without FEC: 0x10 [16] (RECOMMENDED) 750 Certificate: Registry on Aircraft (200 bytes): 751 A certificate granted by the Registry that asserts the 752 binding of UA to the given Registry. 754 With Message Pack the following SHOULD be included in it when sending 755 a DRIP Certificate Message: 1x Location Message 1x Authentication 756 Message, DRIP AuthType 16 The Certificate Message (without FEC) only 757 needs 9 pages for transmission, allowing the final 25 bytes to be 758 used for another ASTM Message. 760 6.2. Message Pack Signature 761 0 1 2 3 762 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 763 +---------------+---------------+---------------+---------------+ 764 | Trust Timestamp | 765 +---------------+---------------+---------------+---------------+ 766 | | 767 | | 768 | | 769 | | 770 | | 771 | | 772 | | 773 | Signature | 774 | | 775 | | 776 | | 777 | | 778 | | 779 | | 780 | | 781 | | 782 +---------------+---------------+---------------+---------------+ 784 Trust Timestamp: (4 bytes) 785 Timestamp denoting current time plus an offset to trust 786 message to. 788 Signature: (64 bytes) 789 Signature over all messages in Message Pack using the 790 EdDSA25519 keypair. 792 The DRIP Message Pack Signature is a DRIP AuthType 0. All messages 793 in the message pack (excluding the Authentication Message itself) is 794 signed. 796 7. Examples 798 7.1. 2 Wrapped ASTM Messages 800 Page 0: 801 0 1 2 3 802 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 803 +---------------+-----------------------------------------------+ 804 |1 1 0 1 0 0 0 0| | 805 +---------------+ ASTM Authentication Headers +---------------+ 806 | |1 0 0 0 0 0 1 0| 807 +-----------------------------------------------+---------------+ 808 | | 809 | UA Hierarchical | 810 | Host Identity Tag | 811 | | 812 +---------------------------------------------------------------+ 814 Page 1: 815 0 1 2 3 816 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 817 +---------------+-----------------------------------------------+ 818 |1 1 0 1 0 0 0 1| Trust Timestamp / 819 +---------------+-----------------------------------------------+ 820 / | | 821 +---------------+ | 822 | | 823 | ASTM Message #1 (Bytes 1 - 19) | 824 | | 825 | | 826 +---------------------------------------------------------------+ 828 Page 2: 829 0 1 2 3 830 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 831 +---------------+-----------------------------------------------+ 832 |1 1 0 1 0 0 1 0| ASTM Message #1 (Bytes 20 - 25) | 833 +---------------+ +---------------+ 834 | | | 835 +-----------------------------------------------+ | 836 | | 837 | ASTM Message #2 (Bytes 1 - 17) | 838 | | 839 | | 840 +---------------------------------------------------------------+ 842 Page 3: 843 0 1 2 3 844 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 845 +---------------+-----------------------------------------------+ 846 |1 1 0 1 0 0 1 1| | 847 +---------------+ | 848 | ASTM Message #2 (Bytes 18 - 25) | 849 | +-----------------------------------------------+ 850 | | | 851 +---------------+ | 852 | Signature (Bytes 1 - 15) | 853 | | 854 | | 855 +---------------------------------------------------------------+ 856 Page 4: 857 0 1 2 3 858 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 859 +---------------+-----------------------------------------------+ 860 |1 1 0 1 0 1 0 0| | 861 +---------------+ | 862 | | 863 | Signature (Bytes 16 - 38) | 864 | | 865 | | 866 | | 867 +---------------------------------------------------------------+ 869 Page 5: 870 0 1 2 3 871 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 872 +---------------+-----------------------------------------------+ 873 |1 1 0 1 0 1 0 1| | 874 +---------------+ | 875 | | 876 | Signature (Bytes 38 - 61) | 877 | | 878 | | 879 | | 880 +---------------------------------------------------------------+ 882 Page 6: 883 0 1 2 3 884 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 885 +---------------+-----------------------------------------------+ 886 |1 1 0 1 0 1 1 0| Signature (Bytes 62 - 64) | 887 +---------------+-----------------------------------------------+ 888 | | 889 | | 890 | Null Padding | 891 | | 892 | | 893 +---------------------------------------------------------------+ 895 Page 7: 896 0 1 2 3 897 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 898 +---------------+-----------------------------------------------+ 899 |1 1 0 1 0 1 1 1| | 900 +---------------+ | 901 | | 902 | Forward Error Correction | 903 | | 904 | | 905 | | 906 +---------------------------------------------------------------+ 908 8. Security Considerations 910 TBD 912 9. ASTM Considerations 914 1. Increase Authentication Page Count maximum from 5 to 10. 916 2. Add Authentication Type for DRIP. 918 10. Acknowledgments 920 Ryan Quigley and James Mussi at AX Enterprize for early prototyping 921 to find holes in the draft specifications. 923 11. References 925 11.1. Normative References 927 [NIST.SP.800-185] 928 Kelsey, J., Change, S., and R. Perlner, "SHA-3 derived 929 functions: cSHAKE, KMAC, TupleHash and ParallelHash", 930 National Institute of Standards and Technology report, 931 DOI 10.6028/nist.sp.800-185, December 2016, 932 . 934 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 935 Requirement Levels", BCP 14, RFC 2119, 936 DOI 10.17487/RFC2119, March 1997, 937 . 939 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 940 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 941 May 2017, . 943 11.2. Informative References 945 [drip-identity-claims] 946 Wiethuechter, A., Card, S., and R. Moskowitz, "DRIP 947 Identity Claims", Work in Progress, Internet-Draft, draft- 948 wiethuechter-drip-identity-claims-00, 23 March 2020, 949 . 952 [drip-requirements] 953 Card, S., Wiethuechter, A., Moskowitz, R., and A. Gurtov, 954 "Drone Remote Identification Protocol (DRIP) 955 Requirements", Work in Progress, Internet-Draft, draft- 956 ietf-drip-reqs-03, 13 July 2020, 957 . 959 [drip-uas-rid] 960 Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov, 961 "UAS Remote ID", Work in Progress, Internet-Draft, draft- 962 moskowitz-drip-uas-rid-03, 13 July 2020, 963 . 966 [F3411-19] ASTM International, "Standard Specification for Remote ID 967 and Tracking", February 2020, 968 . 970 [hierarchical-hit] 971 Moskowitz, R., Card, S., and A. Wiethuechter, 972 "Hierarchical HITs for HIPv2", Work in Progress, Internet- 973 Draft, draft-moskowitz-hip-hierarchical-hit-05, 13 May 974 2020, . 977 [new-hip-crypto] 978 Moskowitz, R., Card, S., and A. Wiethuechter, "New 979 Cryptographic Algorithms for HIP", Work in Progress, 980 Internet-Draft, draft-moskowitz-hip-new-crypto-04, 23 981 January 2020, . 984 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 985 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 986 RFC 7401, DOI 10.17487/RFC7401, April 2015, 987 . 989 Appendix A. Thoughts on ASTM Authentication Message 991 The format standardized by the ASTM is designed with a few major 992 considerations in mind, which the authors of this document feel put 993 significant limitations on the expansion of the standard. 995 The primary consideration (in this context) is the use of the 996 Bluetooth 5.X Extended Frame format. This method allows for a 255 997 byte payload to be sent in what the ASTM refers to as a "Message 998 Pack". 1000 The idea is to include up to five standard ASTM Broadcast RID 1001 messages (each of which are 25 bytes) plus a single authentication 1002 message (5 pages of 25 bytes each) in the Message Pack. The 1003 reasoning is then the Authentication Message is for the entire 1004 Message Pack. 1006 The authors have no issues with this proposed approach; this is a 1007 valid format to use for the Authentication Message provided by the 1008 ASTM. However, by limiting the Authentication Message to ONLY five 1009 pages in the standard it ignores the possibility of other formatting 1010 options to be created and used. 1012 Another issue with this format, not fully addressed in this document 1013 is fragmentation. Under Bluetooth 4.X, each page is sent separately 1014 which can result in lose of pages on the receiver. This is 1015 disastrous as the loss of even a single page means any signature is 1016 incomplete. 1018 With the current limitation of 5 pages, Forward Error Correction 1019 (FEC) is nearly impossible without sacrificing the amount of data 1020 sent. More pages would allow FEC to be performed on the 1021 Authentication Message pages so loss of pages can be mitigated. 1023 All these problems are further amplified by the speed at which UA fly 1024 and the Observer's position to receive transmissions. There is no 1025 guarantee that the Observer will receive all the pages of even a 5 1026 page Authentication Message in the time it takes a UA to traverse 1027 across their line of sight. Worse still is that is not including 1028 other UA in the area, which congests the spectrum and could cause 1029 further confusion attempting to collate messages from various UA. 1030 This specific problem is out of scope for this document and our 1031 solutions in general, but should be noted as a design consideration. 1033 Authors' Addresses 1035 Adam Wiethuechter 1036 AX Enterprize 1037 4947 Commercial Drive 1038 Yorkville, NY 13495 1039 United States of America 1041 Email: adam.wiethuechter@axenterprize.com 1043 Stuart W. Card 1044 AX Enterprize 1045 4947 Commercial Drive 1046 Yorkville, NY 13495 1047 United States of America 1049 Email: stu.card@axenterprize.com 1051 Robert Moskowitz 1052 HTT Consulting 1053 Oak Park, MI 48237 1054 United States of America 1056 Email: rgm@labs.htt-consult.com