idnits 2.17.1 draft-wiethuechter-drip-auth-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 (10 July 2020) is 1385 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: '0xF' is mentioned on line 545, but not defined == Missing Reference: '0x2' is mentioned on line 545, but not defined Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: 11 January 2021 R. Moskowitz 6 HTT Consulting 7 10 July 2020 9 DRIP Authentication Formats 10 draft-wiethuechter-drip-auth-01 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 11 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 1.2. Terms and Definitions . . . . . . . . . . . . . . . . . . 3 57 1.2.1. Requirements Terminology . . . . . . . . . . . . . . 3 58 1.2.2. Definitions . . . . . . . . . . . . . . . . . . . . . 3 59 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Problem Space And Document Focus . . . . . . . . . . . . 4 61 2.2. ASTM Authentication Message . . . . . . . . . . . . . . . 4 62 2.3. Thoughts on ASTM Authentication Message . . . . . . . . . 6 63 3. DRIP Authentication Framing Formats . . . . . . . . . . . . . 7 64 3.1. General Frame . . . . . . . . . . . . . . . . . . . . . . 7 65 3.1.1. DRIP Header . . . . . . . . . . . . . . . . . . . . . 8 66 3.1.2. DRIP Authentication Data . . . . . . . . . . . . . . 8 67 3.2. Wrapper Frame . . . . . . . . . . . . . . . . . . . . . . 8 68 3.2.1. UA Hierarchical Host Identity Tag . . . . . . . . . . 10 69 3.2.2. Trust Timestamp . . . . . . . . . . . . . . . . . . . 10 70 3.2.3. Authentication Data . . . . . . . . . . . . . . . . . 11 71 3.2.4. Signature . . . . . . . . . . . . . . . . . . . . . . 11 72 3.2.5. Forward Error Correction . . . . . . . . . . . . . . 11 73 4. Bluetooth 4.X Formats . . . . . . . . . . . . . . . . . . . . 11 74 4.1. Certificate . . . . . . . . . . . . . . . . . . . . . . . 11 75 4.2. ASTM Message Wrapper . . . . . . . . . . . . . . . . . . 13 76 4.3. Manifest . . . . . . . . . . . . . . . . . . . . . . . . 13 77 4.3.1. Hash Algorithm And Operation . . . . . . . . . . . . 13 78 4.3.2. 4 Byte Manifest . . . . . . . . . . . . . . . . . . . 14 79 4.3.3. 8 Byte Manifest . . . . . . . . . . . . . . . . . . . 14 80 4.3.4. Pseudo-blockchain Hashes . . . . . . . . . . . . . . 15 81 4.3.5. Limitations . . . . . . . . . . . . . . . . . . . . . 16 82 4.4. Recommendations . . . . . . . . . . . . . . . . . . . . . 16 83 5. Bluetooth 5 Formats . . . . . . . . . . . . . . . . . . . . . 16 84 5.1. Certificate . . . . . . . . . . . . . . . . . . . . . . . 17 85 5.2. Message Pack Signature . . . . . . . . . . . . . . . . . 17 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 87 7. ASTM Considerations . . . . . . . . . . . . . . . . . . . . . 18 88 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 90 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 91 9.2. Informative References . . . . . . . . . . . . . . . . . 19 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 94 1. Introduction 96 UA Systems (UAS) are usually in a volatile environment when it comes 97 to communication. UA are generally small with little computational 98 (or flying) horsepower to carry standard communication equipment. 99 This limits the mediums of communication to few viable options. 101 Observer systems (e.g. smartphones and tablets) place further 102 constraints on the communication options. The Remote ID Broadcast 103 messages MUST be available to applications on these platforms without 104 modifying the devices. 106 The ASTM standard [F3411-19] focuses on two ways of communicating to 107 a UAS for RID: Broadcast and Network. 109 This document will focus on adding trust to Broadcast RID in the 110 current (and an expanded) authentication message format. 112 1.1. DRIP Requirements Addressed 114 The following [drip-requirements] will be addressed: 116 1. GEN 1: Provable Ownership 118 2. GEN 2: Provable Binding 120 3. GEN 3: Provable Registration 122 1.2. Terms and Definitions 124 1.2.1. Requirements Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 128 "OPTIONAL" in this document are to be interpreted as described in BCP 129 14 [RFC2119] [RFC8174] when, and only when, they appear in all 130 capitals, as shown here. 132 1.2.2. Definitions 134 See [drip-requirements] for common DRIP terms. 136 2. Background 137 2.1. Problem Space And Document Focus 139 The current standard for Remote ID (RID) does not, in any meaningful 140 capacity, address the concerns of trust in the UA space with 141 communication in the Broadcast RID environment. This is a 142 requirement that will need to be addressed eventually for various 143 different parties that have a stake in the UA industry. 145 The following subsections will provide a high level reference to the 146 ASTM standard for authentication messages and how their current 147 limitations effect trust in the Broadcast RID envirorment. 149 2.2. ASTM Authentication Message 150 Page 0: 151 0 1 2 3 152 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 153 +---------------+-----------------------------------------------+ 154 | Auth Header | | 155 +---------------+ ASTM Authentication Headers +---------------+ 156 | | | 157 +-----------------------------------------------+ | 158 | | 159 | | 160 | | 161 | Authentication Data / Signature | 162 | | 163 | | 164 | | 165 +---------------------------------------------------------------+ 167 Page 1 - 4: 168 0 1 2 3 169 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 170 +---------------+-----------------------------------------------+ 171 | Auth Header | | 172 +---------------+ | 173 | | 174 | | 175 | | 176 | | 177 | Authentication Data / Signature | 178 | | 179 | | 180 | | 181 | | 182 +---------------------------------------------------------------+ 184 Auth Header (1 byte): 185 Contains basic Authentication information such as page 186 number and authentication type. 188 ASTM Authentication Headers: (6 bytes) 189 Contains other header information for the authentication 190 message from ASTM UAS RID Standard. 192 Authentication Data / Signature: (109 bytes: 17+23*4) 193 Opaque authentication data. 195 The above diagram is the format defined by ASTM that is the frame 196 which everything this document fits into. The specific details of 197 the ASTM headers are abstracted away as they are not necessarily 198 required for this document. 200 One important detail that is relevant is the Authentication page has 201 its own 1 byte header (Auth Header) which contains Authentication 202 Type and Data Page Number. 204 2.3. Thoughts on ASTM Authentication Message 206 The format standardized by the ASTM is designed with a few major 207 considerations in mind, which the authors feel put significant 208 limitations on the expansion of the standard. 210 The primary consideration (in this context) is the use of the 211 Bluetooth 5.X Extended Frame format. This method allows for a 255 212 byte payload to be sent in what the ASTM refers to as a "Message 213 Pack". 215 The idea is to include up to five standard ASTM Broadcast RID 216 messages (each of which are 25 bytes) plus a single authentication 217 message (5 pages of 25 bytes each) in the Message Pack. The 218 reasoning is then the authentication message is for the entire 219 Message Pack. 221 The authors have no issues with this proposed approach; this is a 222 valid format to use for the authentication message provided by the 223 ASTM. However, by limiting the authentication message to ONLY five 224 pages in the standard it ignores the possibility of other formatting 225 options to be created and used. 227 Another issue with this format, not fully addressed in this document 228 is fragmentation. Under Bluetooth 4.X, each page is sent seperately 229 which can result in lose of pages on the reciever. This is 230 disasterous as the loss of even a single page means any signature is 231 incomplete. 233 With the current limitation of 5 pages, Forward Error Correction 234 (FEC) is nearly impossible without sacrificing the amount of data 235 sent. More pages would allow FEC to be performed on the Authentation 236 message pages so loss of pages can be mitigated. 238 All these problems are further amplified by the speed at which UA fly 239 and the Oberserver's position to recieve transmissions. There is no 240 guarentee that the Observer will recieve all the pages of even a 5 241 page Authentication Message in the time it takes a UA to traverse 242 across their line of sight. Worse still is that is not including 243 other UA in the area, which congestes the spectrum and could cause 244 further confusion attempting to collate messages from various UA. 246 This specific problem is out of scope for this document and our 247 solutions in general, but should be noted as a design consideration. 249 3. DRIP Authentication Framing Formats 251 Currently the ASTM AuthType of 0xD should be used to denote DRIP 252 based Authentication. 254 3.1. General Frame 256 Page 0: 257 0 1 2 3 258 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 259 +---------------+-----------------------------------------------+ 260 | Auth Header | | 261 +---------------+ ASTM Authentication Headers +---------------+ 262 | | DRIP Header | 263 +-----------------------------------------------+---------------+ 264 | | 265 | | 266 | | 267 | DRIP Authentication Data | 268 | | 269 | | 270 | | 271 +---------------------------------------------------------------+ 273 Page 1 - 9: 274 0 1 2 3 275 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 276 +---------------+-----------------------------------------------+ 277 | Auth Header | | 278 +---------------+ | 279 | | 280 | | 281 | | 282 | DRIP Authentication Data | 283 | | 284 | | 285 | | 286 | | 287 | | 288 +---------------------------------------------------------------+ 290 DRIP Header (1 byte): 291 Message Type (4 bits): 292 Message Type Values 293 ------------ ------ 294 Wrapped ASTM Message 0-1, 3-E 295 DRIP Authentication Message 2 297 DRIP AuthType (4 bits): 298 Only used with upper 4 bits are 0x2. 300 AuthType Values 301 -------- ------ 302 Certificate 0 303 Message Pack Signature 1 304 4 Byte Manifest (cSHAKE128) 2 305 8 Byte Manifest (cSHAKE128) 3 307 DRIP Authentication Data (223 bytes): 308 DRIP Authentication data up to 223 bytes long. 310 3.1.1. DRIP Header 312 The DRIP Header consists of two 4 bit fields and should be read as 313 follows. 315 First when wrapping an ASTM Message (see Section 4.3) the DRIP Header 316 is filled with the first byte of the full 25 byte ASTM Message. This 317 first byte is always the ASTM Header, which contains the Message Type 318 and Protocol Version. 320 To determine if a DRIP Authentication Message is actually wrapping an 321 ASTM Message the upper 4 bits of the DRIP Header should be checked. 322 If these bits are anything but 0x2 then the message is a wrapped 323 message. 325 When the upper 4 bits are 0x2 then the Authentication Message is a 326 specific DRIP format, which is defined in the lower 4 bits of the 327 DRIP Header. 329 3.1.2. DRIP Authentication Data 331 This field has a maximum size of 223 bytes. If the data is less than 332 223 bytes and a page is only partially filled then the rest of the 333 partially filled page must be null padded. 335 3.2. Wrapper Frame 337 0 1 2 3 338 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 339 +---------------+---------------+---------------+---------------+ 340 | | 341 | UA Hierarchical | 342 | Host Identity Tag | 343 | | 344 +---------------+---------------+---------------+---------------+ 345 | Trust Timestamp | 346 +---------------+---------------+---------------+---------------+ 347 | | 348 . . 349 . Authentication Data . 350 . . 351 | | 352 +---------------+---------------+---------------+---------------+ 353 | | 354 | | 355 | | 356 | | 357 | | 358 | | 359 | | 360 | Signature | 361 | | 362 | | 363 | | 364 | | 365 | | 366 | | 367 | | 368 | | 369 +---------------+---------------+---------------+---------------+ 370 | | 371 | | 372 | Forward Error Correction | 373 | | 374 | | 375 | +---------------+ 376 | | 377 +---------------+---------------+---------------+ 379 UA Hierarchial Host Identity Tag (16 bytes): 380 The UAs HHIT in byte form. Hashed from the EdDSA25519 381 public key. 383 Trust Timestamp (4 bytes): 384 Timestamp denoting current time plus an offset to trust 385 message to. 387 Authentication Data (116 bytes): 388 Opaque authentication data using DRIP format specified in 389 the DRIP Header (not shown here). Up to 116 bytes. 391 Signature (64 bytes): 392 Signature over precedding fields using the EdDSA25519 393 keypair. 395 Forward Error Correction (23 bytes): 396 Mandatory under Bluetooth 4.X. Always last auth page. 397 Reed Solomon across precedding pages. 399 This framing resides within the General Frame's DRIP Authentication 400 Data section. 402 3.2.1. UA Hierarchical Host Identity Tag 404 To avoid needing to the the UAs HHIT via the ASTM Basic ID in a 405 detached fashion the 16 byte HHIT is included in the wrapper frame. 407 The HHIT for the UA (and other entities in the RID and greater UTM 408 system under DRIP) is an enhancement of the Host Identity Tag (HIT) 409 of HIPv2 [RFC7401] introducing hierarchy as defined in HHIT 410 [hierarchical-hit]. 412 Using Hierarchical HITs for UAS RID is outlined in HHIT based UAS RID 413 [drip-uas-rid]. 415 3.2.2. Trust Timestamp 417 Trust Timestamp MUST be current UNIX time plus an offset into the 418 future. 420 To avoid replay attacks the Trust Timestamp field must be well 421 founded. When wrapping a vector (position) message the payload WILL 422 contain (by ASTM rules) constantly changing data, this includes its 423 own timestamp. In this case the Trust Timestamp could be argued as 424 superfoulous. 426 Other message types, such as Basic ID and Self-ID are static messages 427 with no changing data. To protect a replay of these signed messages 428 the Trust Timestamp is the field during signing to be guarenteed to 429 change. 431 The offset used against the UNIX timestamp is not defined in this 432 document. Best practices to identify a acceptable offset should be 433 used taking into consideration the UA envirorment, and propgation 434 characteristics of the messages being sent. 436 3.2.3. Authentication Data 438 This field has a max of 116 bytes in length. 440 3.2.4. Signature 442 The wrapper signature is generated using the private key half of the 443 the UAs Host Identity (HI) and is done over all precedding data. 444 ASTM/DRIP Headers are exclude from this operation. 446 3.2.5. Forward Error Correction 448 To help Bluetooth 4 achieve the goal of reliable reciept of paged 449 messages a Forward Error Correction (FEC) scheme is introduced and is 450 mandatory under DRIP. 452 Due to the nature of Bluetooth 4 and the existing ASTM paging 453 structure an optomization can be used. If a Bluetooth frame fails 454 its CRC check, then the frame is dropped without notification to the 455 upper protocol layers. From the Remote ID perspective this means the 456 loss of a complete frame/message/page. In Authentication messages, 457 each page is already numbered so the loss of a page allows the 458 recieving application to build a "dummy" page filled with nulls 459 (other than the ASTM Header which is known). 461 The prefered form of FEC is using Reed Solomon. With this the entire 462 authentication message (all pages, including headers) are used to 463 generate 23 bytes of parity. This parity is appended in one full 464 page (always the last) allowing for recovery when any single page is 465 lost in transmission. 467 If more than one page is lost (>1/5 for 5 page messages, >1/10 for 10 468 page messages) than the error rate of the link is already beyond 469 saving and the application has more issues to deal with. 471 4. Bluetooth 4.X Formats 473 With Bluetooth 4.X formatting the goal is to attempt to bring 474 reliable reciept of paged messages. 476 4.1. Certificate 477 0 1 2 3 478 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 479 +---------------+---------------+---------------+---------------+ 480 | | 481 . . 482 . Certificate: Registry on Aircraft . 483 . . 484 | | 485 +---------------+---------------+---------------+---------------+ 486 | | 487 | | 488 | Forward Error Correction | 489 | | 490 | | 491 | +---------------+ 492 | | 493 +---------------+---------------+---------------+ 495 Certificate: Registry on Aircraft (200 bytes): 496 A certificate granted by the Registry that asserts the 497 binding of UA to the given Registry. 499 Forward Error Correction (23 bytes): 500 Mandatory under Bluetooth 4.X. Reed Solomon across precedding 501 fields (including ASTM/DRIP Headers). 503 This DRIP Authentication type uses the General Frame format, filling 504 the DRIP Authentication Data field with a 200 byte Certificate and 23 505 bytes of Reed Solomon FEC. 507 What this grants is the ability to authenticate UA information when 508 the receiving device of the observer (e.g. a smartphone with a 509 dedicated RID application) has no Internet service (e.g. LTE 510 signal). 512 The Certificate: Registry on Aircraft (Cra) is in practice a binding 513 claim between the Registry and the Aircraft, asserting the 514 relationship between the two entities. Cra signs another 515 certificate, Caa (Certificate: Aircraft on Aircraft), that is created 516 during UA provisioning. 518 Importantly this certificate allows offline signature verification 519 from the UA. This is as the UA HI is included in the certificate. 520 Also included is the HHIT of the Registry to check the local 521 shortlist of Registries that the Observer device trusts (mapping 522 HHITs to HIs). 524 More details about Caa, Cra, other certificates and the provisioning 525 process can be found in [drip-identity-claims]. 527 4.2. ASTM Message Wrapper 529 0 1 2 3 530 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 531 +---------------+---------------+---------------+---------------+ 532 | | 533 . . 534 . ASTM Message: Type 0-1, 3-5 . 535 . . 536 | | 537 +---------------+---------------+---------------+---------------+ 539 ASTM Message: Type 0-1, 3-5 (24 bytes): 540 A valid ASTM Message of Types 0, 1, 3, 4, or 5. First byte 541 (ASTM Header) removed and used as DRIP Header. 543 This DRIP Authentication type uses the Wrapper Frame format, filling 544 the Authentication Data field with an ASTM Message (all types except 545 Message Pack [0xF] and Authentication [0x2]). 547 The first byte of the wrapped message should be used to fill in the 548 DRIP Header field. This corresponds directly with the ASTM Header 549 field and can be used by the reciever to decode the wrapped message. 551 4.3. Manifest 553 By hashing previously sent messages and signing them we gain trust in 554 UAs previous reports. An observer who has been listening for any 555 length of time can hash received messages and cross check against 556 listed hashes. The signature is signed across the list of hashes. 558 4.3.1. Hash Algorithm And Operation 560 The recommended hash to implement as a baseline is cSHAKE128 from 561 [NIST.SP.800-185]. With cSHAKE128, the hash is computed as follows: 563 cSHAKE128(MAC|Message, 8*H-Len, "", "RemoteID Auth Hash") 565 The message MAC is prepended to the message, as the MAC is the only 566 information that links a UA's messages from a specific UA. 568 Other hash algorithms can be considered and used. In this scenario 569 an unused DRIP AuthType can be allocated for such. 571 4.3.2. 4 Byte Manifest 573 0 1 2 3 574 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 575 +---------------+---------------+---------------+---------------+ 576 | Hash of Previous Manifest | 577 +---------------+---------------+---------------+---------------+ 578 | Hash of Current Manifest | 579 +---------------+---------------+---------------+---------------+ 580 | Message Hash 1 | 581 +---------------+---------------+---------------+---------------+ 582 | Message Hash 2 | 583 +---------------+---------------+---------------+---------------+ 584 . . 585 . . 586 . . 587 +---------------+---------------+---------------+---------------+ 588 | Message Hash 27 | 589 +---------------+---------------+---------------+---------------+ 591 Hash of Previous Manifest: (4 bytes) 592 A hash of the previously sent Authentication message. 594 Hash of Current Manifest: (4 bytes) 595 A hash of the current Authentication message. 597 Message Hash: (4 bytes) 598 A hash of a previously sent message. 27 max. 600 4.3.3. 8 Byte Manifest 601 0 1 2 3 602 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 603 +---------------+---------------+---------------+---------------+ 604 | Hash of Previous Manifest | 605 | | 606 +---------------+---------------+---------------+---------------+ 607 | Hash of Current Manifest | 608 | | 609 +---------------+---------------+---------------+---------------+ 610 | Message Hash 1 | 611 | | 612 +---------------+---------------+---------------+---------------+ 613 | Message Hash 2 | 614 | | 615 +---------------+---------------+---------------+---------------+ 616 . . 617 . . 618 . . 619 +---------------+---------------+---------------+---------------+ 620 | Message Hash 12 | 621 | | 622 +---------------+---------------+---------------+---------------+ 624 Hash of Previous Manifest: (8 bytes) 625 A hash of the previously sent Authentication message. 627 Hash of Current Manifest: (8 bytes) 628 A hash of the current Authentication message. 630 Message Hash: (8 bytes) 631 A hash of a previously sent message. 12 max. 633 4.3.4. Pseudo-blockchain Hashes 635 Two special hashes are included; a previous manifest hash, which 636 links to the previous manifest message, as well as a current manifest 637 hash. This gives a pseudo-blockchain provenance to the manifest 638 message that could be traced back if the observer was present for 639 extended periods of time. 641 In regards to the creation and use of the current manifest hash 642 field: 644 During creation and signing of this message format this field MUST 645 be set to 0. So the signature will be based on this field being 646 0, as well as its own hash. It is an open question of if we 647 compute the hash, then sign or sign then compute. 649 There a few different ways to cycle this message. We can "roll 650 up" the hash of 'current' to 'previous' when needed or to 651 completely recompute the hash. This mostly depends on the 652 previous note. 654 4.3.5. Limitations 656 A potentional limitation to this format is dwell time of the UA. If 657 the UA is not sticking to a general area the most likely the Observer 658 will not obtain many (if not all) of the messages in the manifest. 659 Without the original messages recieved no verification can be done. 660 Examples of such scenarios include delivery or survey UA. 662 4.4. Recommendations 664 Under ASTM Bluetooth 4.X rules transmission of dynamic messages are 665 at a minumum of 1 per second while static messages (which is what 666 Authentication is classified under) are 3 per second. 668 Under DRIP the Certificate Message MUST be transmitted to properly 669 meet the GEN 1 and GEN 3 requirement. 671 The ASTM Message Wrapper and Manifest both satisify the GEN 2 672 requirement. At least one MUST be implemented to comply with the GEN 673 2 requirement. 675 A single Manifest can carry at most (using the full 10 page limit and 676 8 byte hashes) 12 unique hashes of previously sent messages (of any 677 type). This results in a total of 22 (12 + 10) frames of Bluetooth 678 data being transmitted over Bluetooth. 680 In comparison the Message Wrapper sends 5 pages (each a single frame) 681 for each wrapped message. For backwards compatibility the 682 implementation should also send the standard ASTM message that was 683 wrapped for non-DRIP compliant recievers to obtain. This method 684 results in 72 total Bluetooth frames (12 + (12 * 5)) sent [this 685 increases to 84 if using FEC]. 687 The question of which is better suited is up to the implementation. 689 5. Bluetooth 5 Formats 691 Under ASTM specification, Bluetooth 5 transport of Remote ID is to 692 use the Message Pack (Type 0xF) format for all transmissions. Under 693 Message Pack all messages are sent together (in Message Type order) 694 in a single Bluetooth frame (up to 250 bytes). Message Packs are 695 required by ASTM to be sent at a rate of 1 per second (like dynamic 696 messages). 698 This gives the benefit of no longer is there any messsage or page 699 fragmentation in transmission. For this reason the recommended use 700 of FEC such as Reed Solomon using in Bluetooth 4.X is not needed here 701 and is impractical. 703 Any of the Bluetooth 4.X formats can theoretically be used during 704 Bluetooth 5 operation under ASTM, however the following subsections 705 define a number of formats optomized for Message Pack and Bluetooth 706 5. 708 5.1. Certificate 710 0 1 2 3 711 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 712 +---------------+---------------+---------------+---------------+ 713 | | 714 . . 715 . Certificate: Registry on Aircraft . 716 . . 717 | | 718 +---------------+---------------+---------------+---------------+ 720 Certificate: Registry on Aircraft (200 bytes): 721 A certificate granted by the Registry that asserts the 722 binding of UA to the given Registry. 724 With Message Pack the following MUST be included in when sending a 725 DRIP Certificate Message: 1x Location Message 1x Authentication 726 Message, DRIP AuthType 0 The Certificate Message (without FEC) only 727 needs 9 pages for transmission, allowing the final 25 bytes to be 728 used for a Location message. 730 5.2. Message Pack Signature 731 0 1 2 3 732 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 733 +---------------+---------------+---------------+---------------+ 734 | Trust Timestamp | 735 +---------------+---------------+---------------+---------------+ 736 | | 737 | | 738 | | 739 | | 740 | | 741 | | 742 | | 743 | Signature | 744 | | 745 | | 746 | | 747 | | 748 | | 749 | | 750 | | 751 | | 752 +---------------+---------------+---------------+---------------+ 754 Trust Timestamp: (4 bytes) 755 Timestamp denoting current time plus an offset to trust 756 message to. 758 Signature: (64 bytes) 759 Signature over all messages in Message Pack using the 760 EdDSA25519 keypair. 762 The DRIP Message Pack Signature is a DRIP AuthType 1. All messages 763 in the message pack (excluding the authentication message itself) is 764 signed. 766 6. Security Considerations 768 1. Hash lengths (length vs strength/collision rate) 2. replay 769 attacks with timestamps 3. static Cra (issue but nulled if UA signing 770 other stuff dynamically meaning signatures will fail as HI won't 771 match - this is probably a deeper disucssion topic for provisioning 772 security considerations when we get to there) 774 7. ASTM Considerations 776 1. Increase Authentication Page Count Max from 5 to 10. 2. Add 777 Authentication Type for DRIP (currently using 0xD) 779 8. Acknowledgments 781 Ryan Quigley and James Mussi at AX Enterprize for early prototyping 782 to find holes in the draft specifications. 784 9. References 786 9.1. Normative References 788 [NIST.SP.800-185] 789 Kelsey, J., Change, S., and R. Perlner, "SHA-3 derived 790 functions: cSHAKE, KMAC, TupleHash and ParallelHash", 791 National Institute of Standards and Technology report, 792 DOI 10.6028/nist.sp.800-185, December 2016, 793 . 795 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 796 Requirement Levels", BCP 14, RFC 2119, 797 DOI 10.17487/RFC2119, March 1997, 798 . 800 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 801 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 802 May 2017, . 804 9.2. Informative References 806 [drip-identity-claims] 807 Wiethuechter, A., Card, S., and R. Moskowitz, "DRIP 808 Identity Claims", Work in Progress, Internet-Draft, draft- 809 wiethuechter-drip-identity-claims-00, 23 March 2020, 810 . 813 [drip-requirements] 814 Card, S., Wiethuechter, A., Moskowitz, R., and A. Gurtov, 815 "Drone Remote Identification Protocol (DRIP) 816 Requirements", Work in Progress, Internet-Draft, draft- 817 ietf-drip-reqs-01, 25 May 2020, 818 . 820 [drip-uas-rid] 821 Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov, 822 "UAS Remote ID", Work in Progress, Internet-Draft, draft- 823 moskowitz-drip-uas-rid-02, 28 May 2020, 824 . 827 [F3411-19] ASTM International, "Standard Specification for Remote ID 828 and Tracking", February 2020, 829 . 831 [hierarchical-hit] 832 Moskowitz, R., Card, S., and A. Wiethuechter, 833 "Hierarchical HITs for HIPv2", Work in Progress, Internet- 834 Draft, draft-moskowitz-hip-hierarchical-hit-05, 13 May 835 2020, . 838 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 839 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 840 RFC 7401, DOI 10.17487/RFC7401, April 2015, 841 . 843 Authors' Addresses 845 Adam Wiethuechter 846 AX Enterprize 847 4947 Commercial Drive 848 Yorkville, NY 13495 849 United States of America 851 Email: adam.wiethuechter@axenterprize.com 853 Stuart W. Card 854 AX Enterprize 855 4947 Commercial Drive 856 Yorkville, NY 13495 857 United States of America 859 Email: stu.card@axenterprize.com 861 Robert Moskowitz 862 HTT Consulting 863 Oak Park, MI 48237 864 United States of America 866 Email: rgm@labs.htt-consult.com