idnits 2.17.1 draft-wiethuechter-drip-auth-00.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 (23 March 2020) is 1495 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: 'SP800-185' is mentioned on line 615, but not defined == Missing Reference: 'Cra' is mentioned on line 921, but not defined == Outdated reference: A later version (-05) exists of draft-moskowitz-hip-hierarchical-hit-04 == Outdated reference: A later version (-10) exists of draft-moskowitz-hip-new-crypto-04 Summary: 0 errors (**), 0 flaws (~~), 5 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: 24 September 2020 R. Moskowitz 6 HTT Consulting 7 23 March 2020 9 DRIP Authentication Formats 10 draft-wiethuechter-drip-auth-00 12 Abstract 14 This document describes how to include trust into the ASTM Remote ID 15 specification defined in ASTM3411 under a Broadcast Remote ID (RID) 16 scenario. It defines a few different message schemes (based on the 17 authentication message) that can be used to assure past messages sent 18 by a UA and also act as an assurance for UA trustworthiness in the 19 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 24 September 2020. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 57 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Problem Space And Document Focus . . . . . . . . . . . . 4 60 3.2. ASTM Authentication Message . . . . . . . . . . . . . . . 4 61 3.3. Thoughts on ASTM Authentication Message . . . . . . . . . 6 62 4. HIP Based Extensions to the ASTM Authentication Message . . . 7 63 4.1. Message Wrapper . . . . . . . . . . . . . . . . . . . . . 7 64 4.1.1. Inner Header . . . . . . . . . . . . . . . . . . . . 9 65 4.1.2. Trust Timestamp . . . . . . . . . . . . . . . . . . . 10 66 4.1.3. Payload . . . . . . . . . . . . . . . . . . . . . . . 10 67 4.1.4. Forward Error Correction . . . . . . . . . . . . . . 10 68 4.2. Signed Hash Lists . . . . . . . . . . . . . . . . . . . . 12 69 4.2.1. Hash Operation . . . . . . . . . . . . . . . . . . . 15 70 4.2.2. Pseudo-blockchain Hashes . . . . . . . . . . . . . . 15 71 4.2.3. Limitations . . . . . . . . . . . . . . . . . . . . . 16 72 4.3. Offline Claim . . . . . . . . . . . . . . . . . . . . . . 16 73 4.3.1. Claim: Registry on Aircraft . . . . . . . . . . . . . 17 74 4.3.2. Foward Error Correction . . . . . . . . . . . . . . . 22 75 5. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 22 76 5.1. Trusted Messages . . . . . . . . . . . . . . . . . . . . 22 77 5.2. Wrapped Signed Hashes . . . . . . . . . . . . . . . . . . 24 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 80 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 82 9.1. Normative References . . . . . . . . . . . . . . . . . . 27 83 9.2. Informative References . . . . . . . . . . . . . . . . . 27 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 86 1. Introduction 88 UA Systems (UAS) are usually in a volatile environment when it comes 89 to communication. UA are generally small with little computational 90 (or flying) horsepower to carry standard communication equipment. 91 This limits the mediums of communication to few viable options. 93 Observer systems (e.g. smartphones and tablets) place further 94 constraints on the communication options. The Remote ID Broadcast 95 messages MUST be available to applications on these platforms without 96 modifying the devices. 98 The ASTM standard focuses on two ways of communicating to a UAS for 99 RID: Broadcast and Network. 101 This document will focus on adding trust to Broadcast RID in the 102 current authentication message format, using the Host Identity 103 Protocol Version 2 (HIPv2) [RFC7401] Hierarchical HIT (HHIT) 104 [I-D.moskowitz-hip-hierarchical-hit]. 106 2. Terms and Definitions 108 2.1. Requirements Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in BCP 113 14 [RFC2119] [RFC8174] when, and only when, they appear in all 114 capitals, as shown here. 116 2.2. Definitions 118 HI 119 Host Identity. The public key portion of an assymetric keypair 120 from HIP. In this document it is assumed that the HI is based on 121 a EdDSA25519 keypair. This is supported by new crypto defined in 122 [I-D.moskowitz-hip-new-crypto]. 124 HIT 125 Host Identity Tag. A 128 bit handle on the HI. Defined in HIPv2 126 [RFC7401]. 128 HHIT 129 Hierarchical Host Identity Tag. A 128 bit handle on the HI contain 130 extra information not found in a standard HIT. Defined in 131 [I-D.moskowitz-hip-hierarchical-hit]. 133 UA 134 Unmanned Aircraft. In this document UA's are typically though of 135 as drones of commerical or military variety. This is a very 136 strict definition which can be relaxed to include any and all 137 aircraft that are unmanned. 139 UAS 140 Unmanned Aircraft System. Composed of Unmanned Aircraft and all 141 required on-board subsystems, payload, control station, other 142 required off-board subsystems, any required launch and recovery 143 equipment, all required crew members, and C2 links between UA and 144 the control station. 146 RID 147 Remote ID. A unique identifier found on all UA to be used in 148 communication and in regulation of UA operation. 150 Observer 151 Referred to in other UAS documents as a "user", but there are also 152 other classes of RID users, so we prefer "observer" to denote an 153 individual who has observed an UA and wishes to know something 154 about it, starting with its RID. 156 3. Background 158 3.1. Problem Space And Document Focus 160 The current standard for Remote ID (RID) does not, in any meaningful 161 capacity, address the concerns of trust in the UA space with 162 communication in the Broadcast RID environment. This is a 163 requirement that will need to be addressed eventually for various 164 different parties that have a stake in the UA industry. 166 The following subsections will provide a high level reference to the 167 ASTM standard for authentication messages and how their current 168 limitations effect trust in the Broadcast RID envirorment. 170 3.2. ASTM Authentication Message 171 Page 0: 172 0 1 2 3 173 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 174 +---------------+-----------------------------------------------+ 175 | ASTM Header | | 176 +---------------+ ASTM Authentication Headers +---------------+ 177 | | | 178 +-----------------------------------------------+ | 179 | | 180 | | 181 | | 182 | Authentication Data / Signature | 183 | | 184 | | 185 | | 186 +---------------------------------------------------------------+ 188 Page 1 - 4: 189 0 1 2 3 190 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 191 +---------------+-----------------------------------------------+ 192 | ASTM Header | | 193 +---------------+ | 194 | | 195 | | 196 | | 197 | | 198 | Authentication Data / Signature | 199 | | 200 | | 201 | | 202 | | 203 +---------------------------------------------------------------+ 205 ASTM Header (1 byte): 206 Contains basic ASTM information such as message type and 207 protocol version. 209 ASTM Authentication Headers: (6 bytes) 210 Contains header information for the authentication message 211 from ASTM UAS RID Standard. 213 Authentication Data / Signature: (109 bytes: 17+23*4) 214 Opaque authentication data. 216 The above diagram is the format defined by ASTM that is the frame 217 which everything this document fits into. The specific details of 218 the ASTM headers are abstracted away as they are not necessarily 219 required for this document. 221 3.3. Thoughts on ASTM Authentication Message 223 The format standardized by the ASTM is designed with a few major 224 considerations in mind, which the authors feel put significant 225 limitations on the expansion of the standard. 227 The primary consideration (in this context) is the use of the 228 Bluetooth 5.X Extended Frame format. This method allows for a 255 229 byte payload to be sent in what the ASTM refers to as a "Message 230 Pack". 232 The idea is to include up to five standard ASTM Broadcast RID 233 messages (each of which are 25 bytes) plus a single authentication 234 message (5 pages of 25 bytes each) in the Message Pack. The 235 reasoning is then the authentication message is for the entire 236 Message Pack. 238 The authors have no issues with this proposed approach; this is a 239 valid format to use for the authentication message provided by the 240 ASTM. However, by limiting the authentication message to ONLY five 241 pages in the standard it ignores the possibility of other formatting 242 options to be created and used. 244 Another issue with this format, not fully addressed in this document 245 is fragmentation. Under Bluetooth 4.X, each page is sent seperately 246 which can result in lose of pages on the reciever. This is 247 disasterous as the loss of even a single page means any signature is 248 incomplete. 250 With the current limitation of 5 pages, Forward Error Correction 251 (FEC) is nearly impossible without sacrificing the amount of data 252 sent. More pages would allow FEC to be performed on the Authentation 253 message pages so loss of pages can be mitigated. 255 All these problems are further amplified by the speed at which UA fly 256 and the Oberserver's position to recieve transmissions. There is no 257 guarentee that the Observer will recieve all the pages of even a 5 258 page Authentication Message in the time it takes a UA to traverse 259 across their line of sight. Worse still is that is not including 260 other UA in the area, which congestes the spectrum and could cause 261 further confusion attempting to collate messages from various UA. 262 This specific problem is out of scope for this document and our 263 solutions in general, but should be noted as a design consideration. 265 4. HIP Based Extensions to the ASTM Authentication Message 267 The following section describes various methods that HIP can help 268 enable more trustworthy communication using the Authentication 269 Message as the base. Each diagram will show all pages of the format 270 filled out. 272 In the future it is probably necessary to have a AuthType assigned by 273 ASTM for DRIP related authentication message formats. How this is 274 accomplished and how it extends if more formats are proposed is still 275 TBD. 277 4.1. Message Wrapper 279 Page 0: 280 0 1 2 3 281 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 282 +---------------+-----------------------------------------------+ 283 | ASTM Header | | 284 +---------------+ ASTM Authentication Headers +---------------+ 285 | | Inner Header | 286 +-----------------------------------------------+---------------+ 287 | | 288 | | 289 | | 290 | HHIT | 291 | | 292 | | 293 | | 294 +---------------------------------------------------------------+ 296 Page 1: 297 0 1 2 3 298 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 299 +---------------+-----------------------------------------------+ 300 | ASTM Header | Trust Timestamp / 301 +---------------+-----------------------------------------------+ 302 / | | 303 +---------------+ | 304 | | 305 | | 306 | Payload (Bytes 1-19) | 307 | | 308 | | 309 | | 310 | | 311 +---------------------------------------------------------------+ 312 Page 2: 313 0 1 2 3 314 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 315 +---------------+-----------------------------------------------+ 316 | ASTM Header | Payload (Bytes 20-24) / 317 +---------------+ +-------------------------------+ 318 / | | 319 +-------------------------------+ | 320 | | 321 | | 322 | | 323 | HHIT Signature (Bytes 1-18) | 324 | | 325 | | 326 | | 327 +---------------------------------------------------------------+ 329 Page 3: 330 0 1 2 3 331 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 332 +---------------+-----------------------------------------------+ 333 | ASTM Header | | 334 +---------------+ | 335 | | 336 | | 337 | | 338 | | 339 | HHIT Signature (Bytes 19-41) | 340 | | 341 | | 342 | | 343 | | 344 +---------------------------------------------------------------+ 346 Page 4: 347 0 1 2 3 348 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 349 +---------------+-----------------------------------------------+ 350 | ASTM Header | | 351 +---------------+ | 352 | | 353 | | 354 | | 355 | | 356 | HHIT Signature (Bytes 42-64) | 357 | | 358 | | 359 | | 360 | | 361 +---------------------------------------------------------------+ 363 Inner Header (1 byte): 364 See Inner Header section. 366 HHIT: (16 bytes) 367 HHIT using the EdDSA25519 HI. 369 Trust Timestamp: (4 bytes) 370 Timestamp denoting current time plus an offset to trust 371 message to. 373 Payload: (24 bytes) 374 Opaque payload data. 376 HHIT Signature: (64 bytes) 377 Signature over precedding fields using the EdDSA25519 keypair. 379 When this authentication format is recieved the HHIT is first looked 380 up in DNS by standard mechanisms to retrieve the HIP RR. From this 381 the HI can be used to perform signature verifiction. The data signed 382 is all the data preceding the 64 byte signature (excluding the ASTM 383 Headers and ASTM Authentication Headers). 385 When there is no Internet connectivity on the Observers device the HI 386 of the UA can be obtained by referencing the claim sent in the 387 Offline Based Authentication format, if sent by the UA. 389 4.1.1. Inner Header 391 When the payload is another ASTM message then the first byte of the 392 full message should be used to fill in the Inner Header field. This 393 byte can be signed but is primarily for identitying the inner message 394 type (for unpacking purposes if desired by the Observer device). 396 Another use of the Inner Header byte is holding the H-Alg and H-Len 397 fields if this format is used for Hashed Messages. See Section 5.2 398 for a detailed example of this. When this format is used all 24 399 bytes of the payload MUST be filled with hash values. This 400 requirement means that only even numbered hash lengths can be used. 402 Any other wrapped messages that are not 24 bytes long and require 403 padding on the payload MUST use the Inner Header to inform the 404 reciever the length of payload in octets. 406 To accomadate payload differences the use of AuthType in the ASTM 407 Authentication Headers section SHOULD be set in the range of 0xA-F 408 (which is availible for Private Use). Only recommended values are 409 defined here, as the allocation in the reserved space of this header 410 is controlled by ASTM. 412 AuthType Values 413 -------- ------ 414 Wrapped ASTM Message A 415 Wrapped Hashes B 416 Wrapped Message Length (octets) C 418 4.1.2. Trust Timestamp 420 Trust Timestamp MUST be current UNIX time plus an offset into the 421 future. 423 To avoid replay attacks the Trust Timestamp field must be well 424 founded. When wrapping a vector (position) message the payload WILL 425 contain (by ASTM rules) constantly changing data, this includes its 426 own timestamp. In this case the Trust Timestamp could be argued as 427 superfoulous. 429 Other message types, such as Basic ID and Self-ID are static messages 430 with no changing data. To protect a replay of these signed messages 431 the Trust Timestamp is the field during signing to be guarenteed to 432 change. 434 The offset used against the UNIX timestamp is not defined in this 435 document. Best practices to identify a acceptable offset should be 436 used taking into consideration the UA envirorment, and propgation 437 characteristics of the messages being sent. 439 4.1.3. Payload 441 The payload can be anything that fits within the 24 byte limit. An 442 example of what could be done with this format is found in 443 Section 5.1. If the payload is less than 24 bytes, null padding MUST 444 be used to fill up to 24 bytes and the AuthType of 0xC MUST be used 445 to identity message size. 447 4.1.4. Forward Error Correction 449 Due to the nature of the wireless link a FEC method is suggested. 450 Under DRIP the Message Wrapper format has two forms of FEC that can 451 be used. 453 Page 5: 454 0 1 2 3 455 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 456 +---------------+-----------------------------------------------+ 457 | ASTM Header | | 458 +---------------+ | 459 | | 460 | | 461 | | 462 | Foward Error Correction | 463 | | 464 | | 465 | | 466 | | 467 | | 468 +---------------------------------------------------------------+ 470 4.1.4.1. Reed Solomon 472 The prefered form of FEC is using Reed Solomon. With this the entire 473 authentication message (all pages, including headers) are used to 474 generate 23 bytes of parity. This parity is appended in one page 475 allowing for recovery when any single page is lost in transmission. 477 4.1.4.2. Exclusive Or 479 This method of FEC is experimental and created by one of the authors 480 during initial prototyping. Note that this format of FEC requires a 481 10-page authentication message, currently unsupported by ASTM. 483 +--------------+ +-----------------------------+ 484 | Page 0: Data |-------------------->| Page 1: XOR(Page 0, Page 2) | 485 +--------------+----+ +---------->+-----------------------------+ 486 | | 487 | | 488 +--------------+----|----+ +-----------------------------+ 489 | Page 2: Data |----|--------------->| Page 3: XOR(Page 2, Page 4) | 490 +--------------+ | +--------->+-----------------------------+ 491 | | 492 | | 493 +--------------+----|-----+ +-----------------------------+ 494 | Page 4: Data |----|--------------->| Page 5: XOR(Page 4, Page 6) | 495 +--------------+ | +--------->+-----------------------------+ 496 | | 497 | | 498 +--------------+----|-----+ +-----------------------------+ 499 | Page 6: Data |----|--------------->| Page 7: XOR(Page 6, Page 8) | 500 +--------------+ | +--------->+-----------------------------+ 501 | | 502 +-----|-----+ 503 +--------------+----------+ | +-----------------------------+ 504 | Page 8: Data | +--->| Page 9: XOR(Page 8, Page 0) | 505 +--------------+-------------------->+-----------------------------+ 507 The above illustration shows the relationship between the 10 page 508 authentication message and the XOR operation performed. 510 The advantage of this format is that a large percentage of the pages 511 can be lost in transmission cand recovered using other pages 512 recieved. 514 The authors are well aware that this has a high overhead (100%) that 515 might be avoided using other methods. In some cases where wireless 516 links are highly congested or weak this could potentionally prove 517 useful. 519 4.2. Signed Hash Lists 521 Page 0: 522 0 1 2 3 523 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 524 +---------------+-----------------------------------------------+ 525 | ASTM Header | | 526 +---------------+ ASTM Authentication Headers +---------------+ 527 | | H-Alg | H-Len | 528 +---------------------------------------------------------------+ 529 | Hash of Previous Auth. Message | 530 +---------------------------------------------------------------+ 531 | Hash of Current Auth. Message | 532 +---------------------------------------------------------------+ 533 | Message Hash | 534 +---------------------------------------------------------------+ 535 | Message Hash | 536 +---------------------------------------------------------------+ 538 Page 1: 539 0 1 2 3 540 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 541 +---------------+---------------+-------------------------------+ 542 | ASTM Header | H-Alg | H-Len | PADDING | 543 +---------------+---------------+-------------------------------+ 544 | Message Hash | 545 +---------------------------------------------------------------+ 546 | Message Hash | 547 +---------------------------------------------------------------+ 548 | Message Hash | 549 +---------------------------------------------------------------+ 550 | Message Hash | 551 +---------------------------------------------------------------+ 552 | Message Hash | 553 +---------------------------------------------------------------+ 555 Page 2: 556 0 1 2 3 557 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 558 +---------------+-----------------------------------------------+ 559 | ASTM Header | PADDING | 560 +---------------+ +-------------------------------+ 561 | | | 562 +-------------------------------+ | 563 | | 564 | | 565 | | 566 | HHIT Signature | 567 | | 568 | | 569 | | 570 +---------------------------------------------------------------+ 572 Page 3: 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 | ASTM Header | | 577 +---------------+ | 578 | | 579 | | 580 | | 581 | | 582 | HHIT Signature | 583 | | 584 | | 585 | | 586 | | 587 +---------------------------------------------------------------+ 589 Page 4: 590 0 1 2 3 591 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 592 +---------------+-----------------------------------------------+ 593 | ASTM Header | | 594 +---------------+ | 595 | | 596 | | 597 | | 598 | | 599 | HHIT Signature | 600 | | 601 | | 602 | | 603 | | 604 +---------------------------------------------------------------+ 606 H-Alg, H-Len: (4 bits), (4 bits) 607 These are fields for relaying information of the Hash 608 algorithm used for the messages and the Hash length (in octets). 609 For this example of the format a length of 4 bytes is 610 used. 612 H-Alg Values 613 ----- ------ 614 RESERVED 0 615 cSHAKE128 1 [SP800-185] (RECOMMENDED) 617 Hash of Previous Auth. Message: (4 bytes) 618 A hash of the previously sent Authentication message. 620 Hash of Current Auth. Message: (4 bytes) 621 A hash of the current Authentication message. 623 Message Hash: (4 bytes) 624 A hash of a previously sent message. 626 HHIT Signature: (64 bytes) 627 EdDSA25519 signature using an EdDSA25519-based HI from HIP. 629 This format is designed to provide provenance to Broadcast RID 630 messages sent by a given UAS. It should be noted that the HHIT is 631 not provided in the format like others specified here - instead it 632 must be obtained via the Basic ID Message in a detached fashion. 634 By hashing previously sent messages and signing them we gain trust in 635 UAS previous reports. An observer who has been listening for any 636 length of time can hash received messages and cross check against 637 listed hashes. The signature is signed across the list of hashes. 639 4.2.1. Hash Operation 641 With cSHAKE128 NIST SP 800-185 [NIST.SP.800-185], the hash is 642 computed as follows: 644 cSHAKE128(MAC|Message, 8*H-Len, "", "RemoteID Auth Hash") 646 The message MAC is prepended to the message, as the MAC is the only 647 information that links a UA's messages from a specific UA. 649 4.2.2. Pseudo-blockchain Hashes 651 Two special hashes are included; a previous authentication hash, 652 which links to the previous signed hash list message, as well as a 653 current hash. This gives a pseudo-blockchain provenance to the 654 authentication message that could be traced back if the observer was 655 present for extended periods of time. 657 In regards to the creation and use of the current authentication hash 658 field: 660 During creation and signing of this message format this field MUST 661 be set to 0. So the signature will be based on this field being 662 0, as well as its own hash. It is an open question of if we 663 compute the hash, then sign or sign then compute. 665 There a few different ways to cycle this message. We can "roll 666 up" the hash of 'current' to 'previous' when needed or to 667 completely recompute the hash. This mostly depends on the 668 previous note. 670 4.2.3. Limitations 672 With the current format proposed by ASTM only 7 messages can be 673 hashed reasonably in the above format. PADDING and redundant H-Alg, 674 H-Len fields could be removed. This would increase the total list of 675 hashes to 9 while losing word alignment of the hashes in each page. 677 To address this problem properly the authors feel that the 678 Authentication Messages needs to have a max bound of 10 pages, 679 instead of 5. 681 4.3. Offline Claim 683 Page 0: 684 0 1 2 3 685 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 686 +---------------+-----------------------------------------------+ 687 | ASTM Header | | 688 +---------------+ ASTM Authentication Headers +---------------+ 689 | | | 690 +-----------------------------------------------+ | 691 | | 692 | | 693 | | 694 | Claim: Registry on Aircraft (Bytes 1-17) | 695 | | 696 | | 697 | | 698 +---------------------------------------------------------------+ 700 Page 1-8: 701 0 1 2 3 702 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 703 +---------------+-----------------------------------------------+ 704 | ASTM Header | | 705 +---------------+ | 706 | | 707 | | 708 | | 709 | Claim: Registry on Aircraft (Bytes 18-200) | 710 | | 711 | | 712 | | 713 | | 714 | | 715 +---------------------------------------------------------------+ 717 Page 9: 719 0 1 2 3 720 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 721 +---------------+-----------------------------------------------+ 722 | ASTM Header | | 723 +---------------+ | 724 | | 725 | | 726 | | 727 | Foward Error Correction | 728 | | 729 | | 730 | | 731 | | 732 | | 733 +---------------------------------------------------------------+ 735 Certificate: Registry on Aircraft (200 bytes): 736 A certificate granted by the Registry that asserts the 737 binding of UA to the given Registry. Note that Page 8's final 738 byte is actually padding. 740 Foward Error Correction (FEC) (23 bytes): 741 FEC on the previous 9 pages. 743 This specific format does not currently fit within the ASTM 744 specification. Requiring a minimum of 200 bytes, this would require 745 the Authentication Message to have 10 pages, instead of the current 5 746 page limit. The rest of this section assumes 10 pages to demonstrate 747 how this message is laid out and works. 749 What this grants is the ability to authenticate UA information when 750 the receiving device of the observer (e.g. a smartphone with a 751 dedicated RID application) has no Internet service (e.g. LTE 752 signal). 754 By including the device HI along with a signature from the registry 755 the UA is under, we can assert trust of a given UA without requiring 756 the need for immediate reverse lookups online. 758 4.3.1. Claim: Registry on Aircraft 760 The bulk of this message is made up with the 200 byte claim titled 761 "Registry on Aircraft" (henceforth refered to as "Cra"). Below is 762 Cra fully marked out inside the ASTM Authentication Message. 764 Page 0: 765 0 1 2 3 766 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 767 +---------------+-----------------------------------------------+ 768 | ASTM Header | | 769 +---------------+ ASTM Authentication Headers +---------------+ 770 | | | 771 +-----------------------------------------------+ | 772 | | 773 | | 774 | Registry HHIT | 775 | | 776 | | 777 | +---------------+ 778 | | UA HHIT (1) | 779 +-----------------------------------------------+---------------+ 781 Page 1: 782 0 1 2 3 783 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 784 +---------------+-----------------------------------------------+ 785 | ASTM Header | | 786 +---------------+ | 787 | | 788 | UA HHIT (2-16) | 789 | | 790 | | 791 | | 792 +---------------------------------------------------------------+ 793 | | 794 | UA HI (1-8) | 795 | | 796 +---------------------------------------------------------------+ 798 Page 2: 799 0 1 2 3 800 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 801 +---------------+-----------------------------------------------+ 802 | ASTM Header | | 803 +---------------+ | 804 | | 805 | | 806 | | 807 | UA HI (9-31) | 808 | | 809 | | 810 | | 811 | | 812 | | 813 +---------------------------------------------------------------+ 815 Page 3: 816 0 1 2 3 817 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 818 +---------------+---------------+-------------------------------+ 819 | ASTM Header | UA HI (32) | UA Expiration / 820 +---------------+---------------+-------------------------------+ 821 / Timestamp | | 822 +-------------------------------+ | 823 | | 824 | | 825 | | 826 | UA Signature (1-18) | 827 | | 828 | | 829 | | 830 +---------------------------------------------------------------+ 832 Page 4: 833 0 1 2 3 834 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 835 +---------------+-----------------------------------------------+ 836 | ASTM Header | | 837 +---------------+ | 838 | | 839 | | 840 | | 841 | | 842 | UA Signature (19-41) | 843 | | 844 | | 845 | | 846 | | 847 +---------------------------------------------------------------+ 849 Page 5: 850 0 1 2 3 851 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 852 +---------------+-----------------------------------------------+ 853 | ASTM Header | | 854 +---------------+ | 855 | | 856 | | 857 | | 858 | | 859 | UA Signature (42-64) | 860 | | 861 | | 862 | | 863 | | 864 +---------------------------------------------------------------+ 866 Page 6: 867 0 1 2 3 868 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 869 +---------------+-----------------------------------------------+ 870 | ASTM Header | Registry Expiration Timestamp / 871 +---------------+-----------------------------------------------+ 872 / | | 873 +---------------+ | 874 | | 875 | | 876 | | 877 | Registry Signature (1-19) | 878 | | 879 | | 880 | | 881 +---------------------------------------------------------------+ 883 Page 7: 884 0 1 2 3 885 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 886 +---------------+-----------------------------------------------+ 887 | ASTM Header | | 888 +---------------+ | 889 | | 890 | | 891 | | 892 | | 893 | Registry Signature (20-42) | 894 | | 895 | | 896 | | 897 | | 898 +---------------------------------------------------------------+ 900 Page 8: 901 0 1 2 3 902 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 903 +---------------+-----------------------------------------------+ 904 | ASTM Header | | 905 +---------------+ | 906 | | 907 | | 908 | | 909 | | 910 | Registry Signature (43-64) | 911 | | 912 | | 913 | +---------------+ 914 | | PADDING | 915 +-----------------------------------------------+---------------+ 917 Registry HHIT (16 bytes): 918 Registry HHIT that UA is registered under and handle 919 for the HI used in the signing of full certificate. 921 Claim: Aircraft on Aircraft [Cra] (116 bytes): 922 UA HHIT (16 bytes): 923 Nominally the Aircraft HHIT (specificed here as UA) 925 UA HI (32 bytes): 926 Public half of EdDSA-25519 asymmetric keypair used 927 to sign Caa. 929 UA Expiration Timestamp (4 bytes): 930 UNIX current time (at time of signing) + offset 932 UA Signature (64 bytes): 933 Signature with UA keypair using the data of UA HHIT, 934 UA HI and UA Expiration Timestamp. 936 Registry Expiration Timestamp (4 bytes): 937 UNIX current time (at time of signing) + offset 939 Registry Signature (64 bytes): 940 Signature with Registry keypair using the data of 941 Registry HHIT, Caa and Registry Expiration Timestamp. 943 Cra is in practice a binding claim between the Registry and the 944 Aircraft, asserting the relationship between the two entities. Cra 945 signs another claim, Caa (Claim: Aircraft on Aircraft), that is 946 created during UA provisioning. 948 Importantly this claim allows offline signature verification from the 949 UA. This is as the UA HI is included in the claim. Also included is 950 the HHIT of the Registry to check the local shortlist of Registries 951 that the Observer device trusts (mapping HHITs to HIs). 953 More details about Caa, Cra, other claims and the provisioning 954 process can be found in [I-D.wiethuechter-tmrid-identity-claims]. 956 4.3.2. Foward Error Correction 958 Page 9: 959 0 1 2 3 960 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 961 +---------------+-----------------------------------------------+ 962 | ASTM Header | | 963 +---------------+ | 964 | | 965 | | 966 | | 967 | Foward Error Correction | 968 | | 969 | | 970 | | 971 | | 972 | | 973 +---------------------------------------------------------------+ 975 The prefered form of FEC is using Reed Solomon. With this the entire 976 authentication message (all pages, including headers) are used to 977 generate 23 bytes of parity. This parity is inserted into the final 978 page of the Claim format for recovery when any single page is lost in 979 transmission. 981 5. Example Use Cases 983 This section introduces potentional use cases of the HIP based 984 extensions to the proposed ASTM standard authentication message. 986 5.1. Trusted Messages 988 Using the HIP Based Authentication Wrapper any single Broadcast RID 989 message defined by ASTM can become what the authors refer to as a 990 "Trusted Message". 992 One specific use case that is useful in the UAS RID space is the 993 creation of a "Trusted Vector Message". By placing a previous [or 994 new] vector message into the payload section of this format a 995 verifiable broadcast can be created. 997 Due to being signed this creates an authentic vector that is hard to 998 spoof, which can confirm flight paths in near real time. 1000 The figure below is a example of a "Trusted Vector Message". 1002 Page 0: 1003 0 1 2 3 1004 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 1005 +---------------+-----------------------------------------------+ 1006 | ASTM Header | | 1007 +---------------+ ASTM Authentication Headers +---------------+ 1008 | | Vector Header | 1009 +-----------------------------------------------+---------------+ 1010 | | 1011 | | 1012 | | 1013 | HHIT | 1014 | | 1015 | | 1016 | | 1017 +---------------------------------------------------------------+ 1019 Page 1: 1020 0 1 2 3 1021 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 1022 +---------------+-----------------------------------------------+ 1023 | ASTM Header | Trust Timestamp / 1024 +---------------+-----------------------------------------------+ 1025 / | | 1026 +---------------+ | 1027 | | 1028 | | 1029 | Vector Message (Bytes 1-19) | 1030 | | 1031 | | 1032 | | 1033 | | 1034 +---------------------------------------------------------------+ 1036 Page 2: 1037 0 1 2 3 1038 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 1039 +---------------+-----------------------------------------------+ 1040 | ASTM Header | Vector Message (Bytes 20-24) / 1041 +---------------+ +-------------------------------+ 1042 / | | 1043 +-------------------------------+ | 1044 | | 1045 | | 1046 | | 1047 | HHIT Signature (Bytes 1-18) | 1048 | | 1049 | | 1050 | | 1051 +---------------------------------------------------------------+ 1053 Page 3: 1054 0 1 2 3 1055 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 1056 +---------------+-----------------------------------------------+ 1057 | ASTM Header | | 1058 +---------------+ | 1059 | | 1060 | | 1061 | | 1062 | | 1063 | HHIT Signature (Bytes 19-41) | 1064 | | 1065 | | 1066 | | 1067 | | 1068 +---------------------------------------------------------------+ 1070 Page 4: 1071 0 1 2 3 1072 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 1073 +---------------+-----------------------------------------------+ 1074 | ASTM Header | | 1075 +---------------+ | 1076 | | 1077 | | 1078 | | 1079 | | 1080 | HHIT Signature (Bytes 42-64) | 1081 | | 1082 | | 1083 | | 1084 | | 1085 +---------------------------------------------------------------+ 1087 5.2. Wrapped Signed Hashes 1089 Using the Message Wrapper a [short] list of hashes can be signed. 1090 These hashes are of previous individual RID messages. 1092 This follows the format of the Signed Hash List, excluding the 1093 psuedo-blockchain hashes found in the Signed Hash List. 1095 To the authors, this format has limited use due to numerous concerns 1096 of replay attacks. It is suggested to instead use the full Signed 1097 Hash List format. 1099 Page 0: 1100 0 1 2 3 1101 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 1102 +---------------+-----------------------------------------------+ 1103 | ASTM Header | | 1104 +---------------+ ASTM Authentication Headers +---------------+ 1105 | | H-Alg | H-Len | 1106 +-----------------------------------------------+---------------+ 1107 | | 1108 | | 1109 | | 1110 | HHIT | 1111 | | 1112 | | 1113 | | 1114 +---------------------------------------------------------------+ 1116 Page 1: 1117 0 1 2 3 1118 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 1119 +---------------+-----------------------------------------------+ 1120 | ASTM Header | Trust Timestamp / 1121 +---------------+-----------------------------------------------+ 1122 / | Message Hash / 1123 +---------------+-----------------------------------------------+ 1124 / | Message Hash / 1125 +---------------+-----------------------------------------------+ 1126 / | Message Hash / 1127 +---------------+-----------------------------------------------+ 1128 / | Message Hash / 1129 +---------------+-----------------------------------------------+ 1130 / | Message Hash / 1131 +---------------------------------------------------------------+ 1133 Page 2: 1134 0 1 2 3 1135 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 1136 +---------------+-----------------------------------------------+ 1137 | ASTM Header / | Message Hash / 1138 +---------------+---------------+-------------------------------+ 1139 / | | 1140 +-------------------------------+ | 1141 | | 1142 | | 1143 | | 1144 | HHIT Signature (Bytes 1-18) | 1145 | | 1146 | | 1147 | | 1148 +---------------------------------------------------------------+ 1150 Page 3: 1151 0 1 2 3 1152 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 1153 +---------------+-----------------------------------------------+ 1154 | ASTM Header | | 1155 +---------------+ | 1156 | | 1157 | | 1158 | | 1159 | | 1160 | HHIT Signature (Bytes 19-41) | 1161 | | 1162 | | 1163 | | 1164 | | 1165 +---------------------------------------------------------------+ 1167 Page 4: 1168 0 1 2 3 1169 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 1170 +---------------+-----------------------------------------------+ 1171 | ASTM Header | | 1172 +---------------+ | 1173 | | 1174 | | 1175 | | 1176 | | 1177 | HHIT Signature (Bytes 42-64) | 1178 | | 1179 | | 1180 | | 1181 | | 1182 +---------------------------------------------------------------+ 1184 6. IANA Considerations 1186 TBD 1188 7. Security Considerations 1190 TBD 1192 8. Acknowledgments 1194 Ryan Quigley and James Mussi at AX Enterprize for early prototyping 1195 to find holes in the draft specifications. 1197 9. References 1199 9.1. Normative References 1201 [NIST.SP.800-185] 1202 Kelsey, J., Change, S., and R. Perlner, "SHA-3 derived 1203 functions: cSHAKE, KMAC, TupleHash and ParallelHash", 1204 National Institute of Standards and Technology report, 1205 DOI 10.6028/nist.sp.800-185, December 2016, 1206 . 1208 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1209 Requirement Levels", BCP 14, RFC 2119, 1210 DOI 10.17487/RFC2119, March 1997, 1211 . 1213 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1214 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1215 May 2017, . 1217 9.2. Informative References 1219 [I-D.moskowitz-hip-hierarchical-hit] 1220 Moskowitz, R., Card, S., and A. Wiethuechter, 1221 "Hierarchical HITs for HIPv2", Work in Progress, Internet- 1222 Draft, draft-moskowitz-hip-hierarchical-hit-04, 3 March 1223 2020, . 1226 [I-D.moskowitz-hip-new-crypto] 1227 Moskowitz, R., Card, S., and A. Wiethuechter, "New 1228 Cryptographic Algorithms for HIP", Work in Progress, 1229 Internet-Draft, draft-moskowitz-hip-new-crypto-04, 23 1230 January 2020, . 1233 [I-D.wiethuechter-tmrid-identity-claims] 1234 Wiethuechter, A., Card, S., and R. Moskowitz, "TMRID 1235 Identity Claims", Work in Progress, Internet-Draft, draft- 1236 wiethuechter-tmrid-identity-claims-01, 9 March 2020, 1237 . 1240 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 1241 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 1242 RFC 7401, DOI 10.17487/RFC7401, April 2015, 1243 . 1245 Authors' Addresses 1247 Adam Wiethuechter 1248 AX Enterprize 1249 4947 Commercial Drive 1250 Yorkville, NY 13495 1251 United States of America 1253 Email: adam.wiethuechter@axenterprize.com 1255 Stuart W. Card 1256 AX Enterprize 1257 4947 Commercial Drive 1258 Yorkville, NY 13495 1259 United States of America 1261 Email: stu.card@axenterprize.com 1263 Robert Moskowitz 1264 HTT Consulting 1265 Oak Park, MI 48237 1266 United States of America 1268 Email: rgm@labs.htt-consult.com