idnits 2.17.1 draft-wiethuechter-tmrid-auth-04.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 (19 December 2019) is 1590 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) == Outdated reference: A later version (-02) exists of draft-moskowitz-hip-hhit-registries-01 == Outdated reference: A later version (-05) exists of draft-moskowitz-hip-hierarchical-hit-02 == Outdated reference: A later version (-10) exists of draft-moskowitz-hip-new-crypto-02 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TMRID A. Wiethuechter 3 Internet-Draft S. Card 4 Intended status: Standards Track AX Enterprize 5 Expires: 21 June 2020 R. Moskowitz 6 HTT Consulting 7 19 December 2019 9 TM-RID Authentication Formats 10 draft-wiethuechter-tmrid-auth-04 12 Abstract 14 This document describes how to include trust into the proposed ASTM 15 Remote ID specification defined in WK65041 by the F38 Committee under 16 a Broadcast Remote ID (RID) scenario. It defines a few different 17 message schemes (based on the authentication message) that can be 18 used to assure past messages sent by a UA and also act as a assurance 19 for UA trustworthiness in the absence of Internet connectivity at the 20 receiving node. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 21 June 2020. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 58 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Problem Space And Document Focus . . . . . . . . . . . . 4 61 3.2. ASTM Authentication Message . . . . . . . . . . . . . . . 4 62 3.3. Thoughts on ASTM Authentication Message . . . . . . . . . 5 63 3.4. TM-RID Supporting Levels . . . . . . . . . . . . . . . . 6 64 4. HIP Based Extensions to the ASTM Authentication Message . . . 6 65 4.1. HIP Based Authentication Wrapper . . . . . . . . . . . . 6 66 4.2. Signed Hash Lists . . . . . . . . . . . . . . . . . . . . 9 67 4.2.1. Hash Operation . . . . . . . . . . . . . . . . . . . 11 68 4.2.2. Pseudo-blockchain Hashes . . . . . . . . . . . . . . 12 69 4.2.3. Limitations . . . . . . . . . . . . . . . . . . . . . 12 70 4.3. HIP Based Offline Authentication . . . . . . . . . . . . 12 71 5. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 14 72 5.1. Trusted Messages . . . . . . . . . . . . . . . . . . . . 14 73 5.2. Wrapped Signed Hashes . . . . . . . . . . . . . . . . . . 16 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 76 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 79 9.2. Informative References . . . . . . . . . . . . . . . . . 19 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 82 1. Introduction 84 UA Systems (UAS) are usually in a volatile environment when it comes 85 to communication. UA are generally small with little computational 86 (or flying) horsepower to carry standard communication equipment. 87 This limits the mediums of communication to few viable options. 89 Observer systems (e.g. smartphones and tablets) place further 90 constraints on the communication options. The Remote ID Broadcast 91 messages MUST be available to applications on these platforms without 92 modifying the devices. 94 The ASTM standard focuses on two ways of communicating to a UAS for 95 RID: Broadcast and Network. 97 This document will focus on adding trust to Broadcast RID in the 98 current authentication message format, using the Host Identity 99 Protocol Version 2 (HIPv2) [RFC7401] Hierarchical HIT (HHIT) 100 [I-D.moskowitz-hip-hierarchical-hit]. 102 2. Terms and Definitions 104 2.1. Requirements Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 108 "OPTIONAL" in this document are to be interpreted as described in BCP 109 14 [RFC2119] [RFC8174] when, and only when, they appear in all 110 capitals, as shown here. 112 2.2. Definitions 114 CAA 115 Civil Aeronautics Administration. An example is the Federal 116 Aviation Administration (FAA) in the United States of America. 118 C2 119 Command and Control. A set of organizational and technical 120 attributes and processes that employs human, physical, and 121 information resources to solve problems and accomplish missions. 122 Mainly used in military contexts. 124 HI 125 Host Identity. The public key portion of an assymetric keypair 126 from HIP. In this document it is assumed that the HI is based on 127 a EdDSA25519 keypair. This is supported by new crypto defined in 128 [I-D.moskowitz-hip-new-crypto]. 130 HIT 131 Host Identity Tag. A 128 bit handle on the HI. Defined in HIPv2 132 [RFC7401]. 134 HHIT 135 Hierarchical Host Identity Tag. A 128 bit handle on the HI contain 136 extra information not found in a standard HIT. Defined in 137 [I-D.moskowitz-hip-hierarchical-hit]. 139 UA 140 Unmanned Aircraft. In this document UA's are typically though of 141 as drones of commerical or military variety. This is a very 142 strict definition which can be relaxed to include any and all 143 aircraft that are unmanned. 145 UAS 146 Unmanned Aircraft System. Composed of Unmanned Aircraft and all 147 required on-board subsystems, payload, control station, other 148 required off-board subsystems, any required launch and recovery 149 equipment, all required crew members, and C2 links between UA and 150 the control station. 152 UTM 153 UAS Traffic Management. A "traffic management" ecosystem for 154 uncontrolled operations that is separate from, but complementary 155 to, the FAA's Air Traffic Management (ATM) system. 157 USS 158 UAS Service Supplier. Provide UTM services to support the UAS 159 community, to connect Operators and other entities to enable 160 information flow across the USS network, and to promote shared 161 situational awareness among UTM participants. (From FAA UTM 162 ConOps V1, May 2018). 164 RID 165 Remote ID. A unique identifier found on all UA to be used in 166 communication and in regulation of UA operation. 168 Observer 169 Referred to in other UAS documents as a "user", but there are also 170 other classes of RID users, so we prefer "observer" to denote an 171 individual who has observed an UA and wishes to know something 172 about it, starting with its RID. 174 3. Background 176 3.1. Problem Space And Document Focus 178 The current draft standard for Remote ID (RID) does not, in any 179 meaningful capacity, address the concerns of trust in the UA space 180 with communication in the Broadcast RID environment. This is a 181 requirement that will need to be addressed eventually for various 182 different parties that have a stake in the UA industry. 184 The following subsections will provide a high level reference to the 185 ASTM standard for authentication messages and how their current 186 limitations effect trust in the Broadcast RID envirorment. 188 3.2. ASTM Authentication Message 189 Page 0: 190 0 1 2 3 191 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 192 +---------------------------------------------------------------+ 193 | | 194 | ASTM UAS RID HEADERS +---------------+ 195 | | | 196 +-----------------------------------------------+ | 197 | | 198 | | 199 | | 200 | Authentication Data / Signature | 201 | | 202 | | 203 | | 204 +---------------------------------------------------------------+ 206 Page 1 - 4: 207 0 1 2 3 208 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 209 +---------------+-----------------------------------------------+ 210 | ASTM HEADER | | 211 +---------------+ | 212 | | 213 | | 214 | | 215 | | 216 | Authentication Data / Signature | 217 | | 218 | | 219 | | 220 | | 221 +---------------------------------------------------------------+ 223 ASTM UAS RID Headers: (7 bytes) 224 Contains header information for the authentication message 225 from ASTM UAS RID Standard. 226 A short 1 byte header is also present as ASTM HEADER included 227 on every page. 229 Authentication Data / Signature: (109 bytes: 17+23*4) 230 Opaque authentication data. 232 3.3. Thoughts on ASTM Authentication Message 234 The format proposed by the ASTM is designed with a few major 235 considerations in mind, which the authors feel put significant 236 limitations on the expansion of the standard. 238 The primary consideration (in this context) is the use of the 239 Bluetooth 5.X Extended Frame format. This method allows for a 255 240 byte payload to be sent in what the ASTM refers to as an "atomic 241 message". 243 The idea is to include up to five standard ASTM Broadcast RID 244 messages (each of which are 25 bytes) plus a single authentication 245 message (5 pages of 25 bytes each) in an atomic message. The 246 reasoning is then the authentication message is for the entire atomic 247 message pack. 249 The authors have no issues with this proposed approach; this is a 250 valid format to use for the authentication message provided by the 251 ASTM. However, by limiting the authentication message to ONLY five 252 pages in the standard it ignores the possibility of other formatting 253 options to be created and used. 255 3.4. TM-RID Supporting Levels 257 This document is assuming that the first two levels of TM-RID 258 (Identification and Authentication) are implemented. This document 259 serves as a expansion to these two levels, leveraging the abilities 260 of the HHIT Registries [I-D.moskowitz-hip-hhit-registries] to its 261 fullest potential. 263 4. HIP Based Extensions to the ASTM Authentication Message 265 The following section describes various methods that HIP can help 266 enable more trustworthy communication using the Authentication 267 Message as the base. Each diagram will show all 5 pages of the 268 format filled out. 270 4.1. HIP Based Authentication Wrapper 272 Page 0: 273 0 1 2 3 274 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 275 +---------------------------------------------------------------+ 276 | | 277 | ASTM UAS RID HEADERS +---------------+ 278 | | RESERVED | 279 +-----------------------------------------------+---------------+ 280 | | 281 | | 282 | | 283 | HHIT | 284 | | 285 | | 286 | | 287 +---------------------------------------------------------------+ 289 Page 1: 290 0 1 2 3 291 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 292 +---------------+-----------------------------------------------+ 293 | ASTM HEADER | Trust Timestamp / 294 +---------------+---------------+-------------------------------+ 295 / | RESERVED | | 296 +---------------+---------------+ | 297 | | 298 | | 299 | | 300 | HHIT Signature | 301 | | 302 | | 303 | | 304 +---------------------------------------------------------------+ 306 Page 2: 307 0 1 2 3 308 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 309 +---------------+-----------------------------------------------+ 310 | ASTM HEADER | | 311 +---------------+ | 312 | | 313 | | 314 | | 315 | | 316 | HHIT Signature | 317 | | 318 | | 319 | | 320 | | 321 +---------------------------------------------------------------+ 323 Page 3: 324 0 1 2 3 325 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 326 +---------------+-----------------------------------------------+ 327 | ASTM HEADER | | 328 +---------------+ | 329 | | 330 | | 331 | | 332 | | 333 | HHIT Signature | 334 | | 335 | | 336 | | 337 | | 338 +---------------------------------------------------------------+ 340 Page 4: 341 0 1 2 3 342 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 343 +---------------+-----------------------------------------------+ 344 | ASTM HEADER | | 345 +---------------+ | 346 | | 347 | | 348 | | 349 | | 350 | Payload | 351 | | 352 | | 353 | | 354 | | 355 +---------------------------------------------------------------+ 357 HHIT: (16 bytes) 358 HHIT using the EdDSA25519 HI. 360 Trust Timestamp: (4 bytes) 361 Timestamp denoting a future time to trust message to. 363 HHIT Signature: (64 bytes) 364 Signature of payload using the EdDSA25519 keypair. 365 Spread across 3 pages. 367 Payload: (0 to 23/25 bytes) 368 Opaque payload data that has been used in signing. 369 This can be increased to 25 by removing padding RESERVED 370 sections. 372 This format is a way to authenticate a given UA using Level 1 and 373 Level 2 of the TM-RID architecture. 375 When this authentication format is recieved the HHIT (provided by 376 Level 1 TM-RID) is first looked up by mechanisms defined in Level 2. 377 This lookup chain ultimately obtains, on the Observers device, the 378 full HI associated with the HHIT recieved. Once completed the 379 signature can then be verifed with the respective data it was signed 380 with. This data, at a minimum would be the payload in the 381 authentication message. 383 The payload can be anything that fits within the 23/25 byte limit. 384 Some examples of what could be done with this format are found in 385 Section 5. 387 4.2. Signed Hash Lists 389 Page 0: 390 0 1 2 3 391 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 392 +---------------------------------------------------------------+ 393 | | 394 | ASTM UAS RID HEADERS +---------------+ 395 | | H-Alg | H-Len | 396 +---------------------------------------------------------------+ 397 | Hash of Previous Auth. Message | 398 +---------------------------------------------------------------+ 399 | Hash of Current Auth. Message | 400 +---------------------------------------------------------------+ 401 | Message Hash | 402 +---------------------------------------------------------------+ 403 | Message Hash | 404 +---------------------------------------------------------------+ 406 DataPage 1: 407 0 1 2 3 408 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 409 +---------------+---------------+-------------------------------+ 410 | ASTM HEADER | H-Alg | H-Len | RESERVED | 411 +---------------+---------------+-------------------------------+ 412 | Message Hash | 413 +---------------------------------------------------------------+ 414 | Message Hash | 415 +---------------------------------------------------------------+ 416 | Message Hash | 417 +---------------------------------------------------------------+ 418 | Message Hash | 419 +---------------------------------------------------------------+ 420 | Message Hash | 421 +---------------------------------------------------------------+ 423 Page 2: 424 0 1 2 3 425 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 426 +---------------+---------------+-------------------------------+ 427 | ASTM HEADER | RESERVED | Signature Length | 428 +---------------+---------------+-------------------------------+ 429 | Signature Algorithm | | 430 +-------------------------------+ | 431 | | 432 | | 433 | | 434 | HHIT Signature | 435 | | 436 | | 437 | | 438 +---------------------------------------------------------------+ 440 Page 3: 441 0 1 2 3 442 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 443 +---------------+-----------------------------------------------+ 444 | ASTM HEADER | | 445 +---------------+ | 446 | | 447 | | 448 | | 449 | | 450 | HHIT Signature | 451 | | 452 | | 453 | | 454 | | 455 +---------------------------------------------------------------+ 457 Page 4: 458 0 1 2 3 459 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 460 +---------------+-----------------------------------------------+ 461 | ASTM HEADER | | 462 +---------------+ | 463 | | 464 | | 465 | | 466 | | 467 | HHIT Signature | 468 | | 469 | | 470 | | 471 | | 472 +---------------------------------------------------------------+ 474 H-Alg, H-Len: (4 bits), (4 bits) 475 These are fields for relaying information of the Hash 476 algorithm used for the messages and the Hash length (in octets). 477 For this example of the format a length of 4 bytes is 478 used. 480 H-Alg Values 481 ----- ------ 482 RESERVED 0 483 cSHAKE128 1 [sp800-185] (RECOMMENDED) 485 Hash of Previous Auth. Message: (4 bytes) 486 A hash of the previously sent Authentication message. 488 Hash of Current Auth. Message: (4 bytes) 489 A hash of the current Authentication message. 491 Message Hash: (4 bytes) 492 A hash of a previously sent message. 494 Signature Length: (2 bytes) 495 Length of signature in octets, excluding Length, and Padding 497 Signature Algorithm: (2 bytes) 498 Self explanatory. 500 HHIT Signature: (64 bytes) 501 EdDSA25519 signature using an EdDSA25519-based HI from HIP. 502 Spread across 3 pages. 504 This format is designed to provide provenance to Broadcast RID 505 messages sent by a given UAS. It should be noted that the HHIT is 506 not provided in the format like others specified here - instead it 507 must be obtained via the Basic ID Message in a detached fashion. 509 By hashing previously sent messages and signing them we gain trust in 510 UAS previous reports. An observer who has been listening for any 511 length of time can hash received messages and cross check against 512 listed hashes. The signature is signed across the list of hashes. 514 4.2.1. Hash Operation 516 With cSHAKE128 NIST SP 800-185 [NIST.SP.800-185], the hash is 517 computed as follows: 519 cSHAKE128(MAC|Message, 8*H-Len, "", "RemoteID Auth Hash") 521 The message MAC is prepended to the message, as the MAC is the only 522 information that links a UA's messages from a specific UA. 524 4.2.2. Pseudo-blockchain Hashes 526 Two special hashes are included; a previous authentication hash, 527 which links to the previous signed hash list message, as well as a 528 current hash. This gives a pseudo-blockchain provenance to the 529 authentication message that could be traced back if the observer was 530 present for extended periods of time. 532 In regards to the creation and use of the current authentication hash 533 field: 535 During creation and signing of this message format this field MUST 536 be set to 0. So the signature will be based on this field being 537 0, as well as its own hash. It is an open question of if we 538 compute the hash, then sign or sign then compute. 540 There a few different ways to cycle this message. We can "roll 541 up" the hash of 'current' to 'previous' when needed or to 542 completely recompute the hash. This mostly depends on the 543 previous note. 545 4.2.3. Limitations 547 With the current format proposed by ASTM only 7 messages can be 548 hashed reasonably in the above format. RESERVED padding, the 549 Signature Algorithm, Signature Length and redundant H-Alg, H-Len 550 fields could be removed. This would increase the total list of 551 hashes to 9 while losing word alignment of the hashes in each page. 553 To address this problem properly the authors feel that the 554 Authentication Messages needs to have a max bound of 10 pages, 555 instead of 5. 557 4.3. HIP Based Offline Authentication 559 0 1 2 3 560 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 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | | 563 | DEV HHIT | 564 | | 565 | | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | TIMESTAMP | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | | 570 | DEV HHIT | 571 | SIG | 572 . . 573 . . 574 . . 575 | | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | | 578 | DEV HI | 579 | | 580 | | 581 | | 582 | | 583 | | 584 | | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | AUTH TIMESTAMP | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | | 589 | AUTH HHIT | 590 | | 591 | | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | | 594 | AUTH | 595 | SIG | 596 . . 597 . . 598 . . 599 | | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 / PAYLOAD / 602 / / 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 DEV HHIT 16 byte Dev HHIT of EdDSA25519 HI 606 TIMESTAMP 4 byte packet trust until timestamp 607 DEV HHIT SIG 64 byte Signature of whole packet 608 DEV HI 32 byte Device HI of EdDSA25519 HI 609 AUTH TIMESTAMP 4 byte Dev HHIT trust until timestamp 610 AUTH HHIT 16 byte Authorizer's HHIT of EdDSA25519 HI 611 AUTH SIG 64 byte Signature of Device HHIT-HI 612 PAYLOAD 0 to n bytes of payload 613 Length 200 + n bytes 615 This specific format does not currently fit within the ASTM 616 specification. Requiring a minimum of 200 bytes, this would require 617 the Authentication Message to have 10 pages, instead of the current 5 618 page limit. 620 What this will grant, if attainable in future revisions of the ASTM 621 specification, is the ability to authenticate UA information when the 622 receiving device of the observer (e.g. a smartphone with a dedicated 623 RID application) has no Internet service (e.g. LTE signal). 625 By including the device HI along with a signature from the registry 626 the UA is under, we can assert trust of a given UA without requiring 627 the need for immediate reverse lookups online. 629 5. Example Use Cases 631 This section introduces potentional use cases of the HIP based 632 extensions to the proposed ASTM standard authentication message. 634 5.1. Trusted Messages 636 Using the HIP Based Authentication Wrapper any single Broadcast RID 637 message defined by ASTM can become what the authors refer to as a 638 "Trusted Message". 640 One specific use case that is useful in the UAS RID space is the 641 creation of a "Trusted Vector Message". By placing a previous [or 642 new] vector message into the Payload section of this format a 643 verifiable broadcast can be created. 645 Due to being signed this creates an authentic vector that is hard to 646 spoof, which can confirm flight paths in near real time. 648 The figure below is a example of a "Trusted Vector Message". Note 649 that the padding (RESERVED) byte are now gone. The "Trust Timestamp" 650 and "Vector Message" fields now span multiple pages instead of being 651 aligned to pages. 653 Page 0: 654 0 1 2 3 655 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 656 +---------------------------------------------------------------+ 657 | | 658 | ASTM UAS RID HEADERS +---------------+ 659 | | | 660 +-----------------------------------------------+ | 661 | | 662 | | 663 | | 664 | HHIT | 665 | | 666 | +---------------+ 667 | | / 668 +-----------------------------------------------+---------------+ 670 Page 1: 671 0 1 2 3 672 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 673 +---------------+-----------------------------------------------+ 674 | ASTM HEADER / Trust Timestamp | 675 +---------------+-----------------------------------------------+ 676 | | 677 | | 678 | | 679 | | 680 | HHIT Signature | 681 | | 682 | | 683 | | 684 | | 685 +---------------------------------------------------------------+ 687 Page 2: 688 0 1 2 3 689 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 690 +---------------+-----------------------------------------------+ 691 | ASTM HEADER | | 692 +---------------+ | 693 | | 694 | | 695 | | 696 | | 697 | HHIT Signature | 698 | | 699 | | 700 | | 701 | | 702 +---------------------------------------------------------------+ 704 Page 3: 705 0 1 2 3 706 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 707 +---------------+-----------------------------------------------+ 708 | ASTM HEADER | | 709 +---------------+ | 710 | | 711 | | 712 | | 713 | HHIT Signature | 714 | | 715 | | 716 | | 717 | +-------------------------------+ 718 | | Vector Message / 719 +-------------------------------+-------------------------------+ 721 Page 4: 722 0 1 2 3 723 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 724 +---------------+-----------------------------------------------+ 725 | ASTM HEADER / | 726 +---------------+ | 727 | | 728 | | 729 | | 730 | | 731 | Vector Message | 732 | | 733 | | 734 | | 735 | | 736 +---------------------------------------------------------------+ 738 5.2. Wrapped Signed Hashes 740 Using the HIP Based Authentication Wrapper a [short] list of hashes 741 can be signed. These hashes are of previous individual RID messages. 743 This follows the format of the Signed Hash List, excluding the 744 psuedo-blockchain hashes and various other fields enabling it to fit 745 within the 23 byte limit of the final page. 747 To the authors, this format has limited use due to numerous concerns 748 of replay attacks. It is suggested to instead use the full Signed 749 Hash List format. 751 Page 0: 752 0 1 2 3 753 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 754 +---------------------------------------------------------------+ 755 | | 756 | ASTM UAS RID HEADERS +---------------+ 757 | | RESERVED | 758 +-----------------------------------------------+---------------+ 759 | | 760 | | 761 | | 762 | HHIT | 763 | | 764 | | 765 | | 766 +---------------------------------------------------------------+ 768 Page 1: 769 0 1 2 3 770 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 771 +---------------+-----------------------------------------------+ 772 | ASTM HEADER | Trust Timestamp / 773 +---------------+---------------+-------------------------------+ 774 / | RESERVED | | 775 +---------------+---------------+ | 776 | | 777 | | 778 | | 779 | HHIT Signature | 780 | | 781 | | 782 | | 783 +---------------------------------------------------------------+ 785 Page 2: 786 0 1 2 3 787 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 788 +---------------+-----------------------------------------------+ 789 | ASTM HEADER | | 790 +---------------+ | 791 | | 792 | | 793 | | 794 | | 795 | HHIT Signature | 796 | | 797 | | 798 | | 799 | | 800 +---------------------------------------------------------------+ 802 Page 3: 803 0 1 2 3 804 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 805 +---------------+-----------------------------------------------+ 806 | ASTM HEADER | | 807 +---------------+ | 808 | | 809 | | 810 | | 811 | | 812 | HHIT Signature | 813 | | 814 | | 815 | | 816 | | 817 +---------------------------------------------------------------+ 819 Page 4: 820 0 1 2 3 821 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 822 +---------------+---------------+-------------------------------+ 823 | ASTM HEADER | H-Alg | H-Len | RESERVED | 824 +---------------+---------------+-------------------------------+ 825 | Message Hash | 826 +---------------------------------------------------------------+ 827 | Message Hash | 828 +---------------------------------------------------------------+ 829 | Message Hash | 830 +---------------------------------------------------------------+ 831 | Message Hash | 832 +---------------------------------------------------------------+ 833 | Message Hash | 834 +---------------------------------------------------------------+ 836 6. IANA Considerations 838 TBD 840 7. Security Considerations 842 TBD 844 8. Acknowledgments 846 TBD 848 9. References 850 9.1. Normative References 852 [NIST.SP.800-185] 853 Kelsey, J., Change, S., and R. Perlner, "SHA-3 derived 854 functions: cSHAKE, KMAC, TupleHash and ParallelHash", 855 National Institute of Standards and Technology report, 856 DOI 10.6028/nist.sp.800-185, December 2016, 857 . 859 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 860 Requirement Levels", BCP 14, RFC 2119, 861 DOI 10.17487/RFC2119, March 1997, 862 . 864 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 865 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 866 May 2017, . 868 9.2. Informative References 870 [I-D.moskowitz-hip-hhit-registries] 871 Moskowitz, R., Card, S., and A. Wiethuechter, 872 "Hierarchical HIT Registries", Work in Progress, Internet- 873 Draft, draft-moskowitz-hip-hhit-registries-01, 17 October 874 2019, . 877 [I-D.moskowitz-hip-hierarchical-hit] 878 Moskowitz, R., Card, S., and A. Wiethuechter, 879 "Hierarchical HITs for HIPv2", Work in Progress, Internet- 880 Draft, draft-moskowitz-hip-hierarchical-hit-02, 17 October 881 2019, . 884 [I-D.moskowitz-hip-new-crypto] 885 Moskowitz, R., Card, S., and A. Wiethuechter, "New 886 Cryptographic Algorithms for HIP", Work in Progress, 887 Internet-Draft, draft-moskowitz-hip-new-crypto-02, 3 888 October 2019, . 891 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 892 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 893 RFC 7401, DOI 10.17487/RFC7401, April 2015, 894 . 896 Authors' Addresses 898 Adam Wiethuechter 899 AX Enterprize 900 4947 Commercial Drive 901 Yorkville, NY 13495 902 United States of America 904 Email: adam.wiethuechter@axenterprize.com 905 Stuart W. Card 906 AX Enterprize 907 4947 Commercial Drive 908 Yorkville, NY 13495 909 United States of America 911 Email: stu.card@axenterprize.com 913 Robert Moskowitz 914 HTT Consulting 915 Oak Park, MI 48237 916 United States of America 918 Email: rgm@labs.htt-consult.com