idnits 2.17.1 draft-wiethuechter-tmrid-auth-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (31 October 2019) is 1638 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: 3 May 2020 R. Moskowitz 6 HTT Consulting 7 31 October 2019 9 TM-RID Authentication Formats 10 draft-wiethuechter-tmrid-auth-03 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 3 May 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 65 Message . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4.1. HIP Based Authentication Wrapper . . . . . . . . . . . . 6 67 4.2. Signed Hash Lists . . . . . . . . . . . . . . . . . . . . 9 68 4.2.1. Hash Operation . . . . . . . . . . . . . . . . . . . 11 69 4.2.2. Pseudo-blockchain Hashes . . . . . . . . . . . . . . 12 70 4.2.3. Limitations . . . . . . . . . . . . . . . . . . . . . 12 71 4.3. HIP Based Offline Authentication . . . . . . . . . . . . 12 72 5. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 14 73 5.1. Trusted Messages . . . . . . . . . . . . . . . . . . . . 14 74 5.2. Wrapped Signed Hashes . . . . . . . . . . . . . . . . . . 16 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 77 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 79 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 80 9.2. Informative References . . . . . . . . . . . . . . . . . 19 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 83 1. Introduction 85 UA Systems (UAS) are usually in a volatile environment when it comes 86 to communication. UA are generally small with little computational 87 (or flying) horsepower to carry standard communication equipment. 88 This limits the mediums of communication to few viable options. 90 Observer systems (e.g. smartphones and tablets) place further 91 constraints on the communication options. The Remote ID Broadcast 92 messages MUST be available to applications on these platforms without 93 modifying the devices. 95 The ASTM standard focuses on two ways of communicating to a UAS for 96 RID: Broadcast and Network. 98 This document will focus on adding trust to Broadcast RID in the 99 current authentication message format, using the Host Identity 100 Protocol Version 2 (HIPv2) [RFC7401] Hierarchical HIT (HHIT) 101 [I-D.moskowitz-hip-hierarchical-hit]. 103 2. Terms and Definitions 105 2.1. Requirements Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 109 "OPTIONAL" in this document are to be interpreted as described in BCP 110 14 [RFC2119] [RFC8174] when, and only when, they appear in all 111 capitals, as shown here. 113 2.2. Definitions 115 CAA Civil Aeronautics Administration. An example is the 116 Federal Aviation Administration (FAA) in the United States 117 of America. 119 C2 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 122 missions. Mainly used in military contexts. 124 HI Host Identity. The public key portion of an assymetric 125 keypair from HIP. In this document it is assumed that the 126 HI is based on a EdDSA25519 keypair. This is supported by 127 new crypto defined in [I-D.moskowitz-hip-new-crypto]. 129 HIT Host Identity Tag. A 128 bit handle on the HI. Defined in 130 HIPv2 [RFC7401]. 132 HHIT Hierarchical Host Identity Tag. A 128 bit handle on the HI 133 contain extra information not found in a standard HIT. 134 Defined in [I-D.moskowitz-hip-hierarchical-hit]. 136 UA Unmanned Aircraft. In this document UA's are typically 137 though of as drones of commerical or military variety. 138 This is a very strict definition which can be relaxed to 139 include any and all aircraft that are unmanned. 141 UAS Unmanned Aircraft System. Composed of Unmanned Aircraft 142 and all required on-board subsystems, payload, control 143 station, other required off-board subsystems, any required 144 launch and recovery equipment, all required crew members, 145 and C2 links between UA and the control station. 147 UTM UAS Traffic Management. A "traffic management" ecosystem 148 for uncontrolled operations that is separate from, but 149 complementary to, the FAA's Air Traffic Management (ATM) 150 system. 152 USS UAS Service Supplier. Provide UTM services to support the 153 UAS community, to connect Operators and other entities to 154 enable information flow across the USS network, and to 155 promote shared situational awareness among UTM 156 participants. (From FAA UTM ConOps V1, May 2018). 158 RID Remote ID. A unique identifier found on all UA to be used 159 in communication and in regulation of UA operation. 161 Observer Referred to in other UAS documents as a "user", but there 162 are also other classes of RID users, so we prefer 163 "observer" to denote an individual who has observed an UA 164 and wishes to know something about it, starting with its 165 RID. 167 3. Background 169 3.1. Problem Space And Document Focus 171 The current draft standard for Remote ID (RID) does not, in any 172 meaningful capacity, address the concerns of trust in the UA space 173 with communication in the Broadcast RID environment. This is a 174 requirement that will need to be addressed eventually for various 175 different parties that have a stake in the UA industry. 177 The following subsections will provide a high level reference to the 178 ASTM standard for authentication messages and how their current 179 limitations effect trust in the Broadcast RID envirorment. 181 3.2. ASTM Authentication Message 182 Page 0: 183 0 1 2 3 184 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 185 +---------------------------------------------------------------+ 186 | | 187 | ASTM UAS RID HEADERS +---------------+ 188 | | | 189 +-----------------------------------------------+ | 190 | | 191 | | 192 | | 193 | Authentication Data / Signature | 194 | | 195 | | 196 | | 197 +---------------------------------------------------------------+ 199 Page 1 - 4: 200 0 1 2 3 201 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 202 +---------------+-----------------------------------------------+ 203 | ASTM HEADER | | 204 +---------------+ | 205 | | 206 | | 207 | | 208 | | 209 | Authentication Data / Signature | 210 | | 211 | | 212 | | 213 | | 214 +---------------------------------------------------------------+ 216 ASTM UAS RID Headers: (7 bytes) 217 Contains header information for the authentication message 218 from ASTM UAS RID Standard. 219 A short 1 byte header is also present as ASTM HEADER included 220 on every page. 222 Authentication Data / Signature: (109 bytes: 17+23*4) 223 Opaque authentication data. 225 3.3. Thoughts on ASTM Authentication Message 227 The format proposed by the ASTM is designed with a few major 228 considerations in mind, which the authors feel put significant 229 limitations on the expansion of the standard. 231 The primary consideration (in this context) is the use of the 232 Bluetooth 5.X Extended Frame format. This method allows for a 255 233 byte payload to be sent in what the ASTM refers to as an "atomic 234 message". 236 The idea is to include up to five standard ASTM Broadcast RID 237 messages (each of which are 25 bytes) plus a single authentication 238 message (5 pages of 25 bytes each) in an atomic message. The 239 reasoning is then the authentication message is for the entire atomic 240 message pack. 242 The authors have no issues with this proposed approach; this is a 243 valid format to use for the authentication message provided by the 244 ASTM. However, by limiting the authentication message to ONLY five 245 pages in the standard it ignores the possibility of other formatting 246 options to be created and used. 248 3.4. TM-RID Supporting Levels 250 This document is assuming that the first two levels of TM-RID 251 (Identification and Authentication) are implemented. This document 252 serves as a expansion to these two levels, leveraging the abilities 253 of the HHIT Registries [I-D.moskowitz-hip-hhit-registries] to its 254 fullest potential. 256 4. HIP Based Extensions to the ASTM Authentication Message 258 The following section describes various methods that HIP can help 259 enable more trustworthy communication using the Authentication 260 Message as the base. Each diagram will show all 5 pages of the 261 format filled out. 263 4.1. HIP Based Authentication Wrapper 265 Page 0: 266 0 1 2 3 267 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 268 +---------------------------------------------------------------+ 269 | | 270 | ASTM UAS RID HEADERS +---------------+ 271 | | RESERVED | 272 +-----------------------------------------------+---------------+ 273 | | 274 | | 275 | | 276 | HHIT | 277 | | 278 | | 279 | | 280 +---------------------------------------------------------------+ 282 Page 1: 283 0 1 2 3 284 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 285 +---------------+-----------------------------------------------+ 286 | ASTM HEADER | Trust Timestamp / 287 +---------------+---------------+-------------------------------+ 288 / | RESERVED | | 289 +---------------+---------------+ | 290 | | 291 | | 292 | | 293 | HHIT Signature | 294 | | 295 | | 296 | | 297 +---------------------------------------------------------------+ 299 Page 2: 300 0 1 2 3 301 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 302 +---------------+-----------------------------------------------+ 303 | ASTM HEADER | | 304 +---------------+ | 305 | | 306 | | 307 | | 308 | | 309 | HHIT Signature | 310 | | 311 | | 312 | | 313 | | 314 +---------------------------------------------------------------+ 316 Page 3: 317 0 1 2 3 318 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 319 +---------------+-----------------------------------------------+ 320 | ASTM HEADER | | 321 +---------------+ | 322 | | 323 | | 324 | | 325 | | 326 | HHIT Signature | 327 | | 328 | | 329 | | 330 | | 331 +---------------------------------------------------------------+ 333 Page 4: 334 0 1 2 3 335 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 336 +---------------+-----------------------------------------------+ 337 | ASTM HEADER | | 338 +---------------+ | 339 | | 340 | | 341 | | 342 | | 343 | Payload | 344 | | 345 | | 346 | | 347 | | 348 +---------------------------------------------------------------+ 350 HHIT: (16 bytes) 351 HHIT using the EdDSA25519 HI. 353 Trust Timestamp: (4 bytes) 354 Timestamp denoting a future time to trust message to. 356 HHIT Signature: (64 bytes) 357 Signature of payload using the EdDSA25519 keypair. 358 Spread across 3 pages. 360 Payload: (0 to 23/25 bytes) 361 Opaque payload data that has been used in signing. 362 This can be increased to 25 by removing padding RESERVED 363 sections. 365 This format is a way to authenticate a given UA using Level 1 and 366 Level 2 of the TM-RID architecture. 368 When this authentication format is recieved the HHIT (provided by 369 Level 1 TM-RID) is first looked up by mechanisms defined in Level 2. 370 This lookup chain ultimately obtains, on the Observers device, the 371 full HI associated with the HHIT recieved. Once completed the 372 signature can then be verifed with the respective data it was signed 373 with. This data, at a minimum would be the payload in the 374 authentication message. 376 The payload can be anything that fits within the 23/25 byte limit. 377 Some examples of what could be done with this format are found in 378 Section 5. 380 4.2. Signed Hash Lists 382 Page 0: 383 0 1 2 3 384 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 385 +---------------------------------------------------------------+ 386 | | 387 | ASTM UAS RID HEADERS +---------------+ 388 | | H-Alg | H-Len | 389 +---------------------------------------------------------------+ 390 | Hash of Previous Auth. Message | 391 +---------------------------------------------------------------+ 392 | Hash of Current Auth. Message | 393 +---------------------------------------------------------------+ 394 | Message Hash | 395 +---------------------------------------------------------------+ 396 | Message Hash | 397 +---------------------------------------------------------------+ 399 DataPage 1: 400 0 1 2 3 401 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 402 +---------------+---------------+-------------------------------+ 403 | ASTM HEADER | H-Alg | H-Len | RESERVED | 404 +---------------+---------------+-------------------------------+ 405 | Message Hash | 406 +---------------------------------------------------------------+ 407 | Message Hash | 408 +---------------------------------------------------------------+ 409 | Message Hash | 410 +---------------------------------------------------------------+ 411 | Message Hash | 412 +---------------------------------------------------------------+ 413 | Message Hash | 414 +---------------------------------------------------------------+ 416 Page 2: 417 0 1 2 3 418 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 419 +---------------+---------------+-------------------------------+ 420 | ASTM HEADER | RESERVED | Signature Length | 421 +---------------+---------------+-------------------------------+ 422 | Signature Algorithm | | 423 +-------------------------------+ | 424 | | 425 | | 426 | | 427 | HHIT Signature | 428 | | 429 | | 430 | | 431 +---------------------------------------------------------------+ 433 Page 3: 434 0 1 2 3 435 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 436 +---------------+-----------------------------------------------+ 437 | ASTM HEADER | | 438 +---------------+ | 439 | | 440 | | 441 | | 442 | | 443 | HHIT Signature | 444 | | 445 | | 446 | | 447 | | 448 +---------------------------------------------------------------+ 450 Page 4: 451 0 1 2 3 452 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 453 +---------------+-----------------------------------------------+ 454 | ASTM HEADER | | 455 +---------------+ | 456 | | 457 | | 458 | | 459 | | 460 | HHIT Signature | 461 | | 462 | | 463 | | 464 | | 465 +---------------------------------------------------------------+ 467 H-Alg, H-Len: (4 bits), (4 bits) 468 These are fields for relaying information of the Hash 469 algorithm used for the messages and the Hash length (in octets). 470 For this example of the format a length of 4 bytes is 471 used. 473 H-Alg Values 474 ----- ------ 475 RESERVED 0 476 cSHAKE128 1 [sp800-185] (RECOMMENDED) 478 Hash of Previous Auth. Message: (4 bytes) 479 A hash of the previously sent Authentication message. 481 Hash of Current Auth. Message: (4 bytes) 482 A hash of the current Authentication message. 484 Message Hash: (4 bytes) 485 A hash of a previously sent message. 487 Signature Length: (2 bytes) 488 Length of signature in octets, excluding Length, and Padding 490 Signature Algorithm: (2 bytes) 491 Self explanatory. 493 HHIT Signature: (64 bytes) 494 EdDSA25519 signature using an EdDSA25519-based HI from HIP. 495 Spread across 3 pages. 497 This format is designed to provide provenance to Broadcast RID 498 messages sent by a given UAS. It should be noted that the HHIT is 499 not provided in the format like others specified here - instead it 500 must be obtained via the Basic ID Message in a detached fashion. 502 By hashing previously sent messages and signing them we gain trust in 503 UAS previous reports. An observer who has been listening for any 504 length of time can hash received messages and cross check against 505 listed hashes. The signature is signed across the list of hashes. 507 4.2.1. Hash Operation 509 With cSHAKE128 NIST SP 800-185 [NIST.SP.800-185], the hash is 510 computed as follows: 512 cSHAKE128(MAC|Message, 8*H-Len, "", "RemoteID Auth Hash") 514 The message MAC is prepended to the message, as the MAC is the only 515 information that links a UA's messages from a specific UA. 517 4.2.2. Pseudo-blockchain Hashes 519 Two special hashes are included; a previous authentication hash, 520 which links to the previous signed hash list message, as well as a 521 current hash. This gives a pseudo-blockchain provenance to the 522 authentication message that could be traced back if the observer was 523 present for extended periods of time. 525 In regards to the creation and use of the current authentication hash 526 field: 528 During creation and signing of this message format this field MUST 529 be set to 0. So the signature will be based on this field being 530 0, as well as its own hash. It is an open question of if we 531 compute the hash, then sign or sign then compute. 533 There a few different ways to cycle this message. We can "roll 534 up" the hash of 'current' to 'previous' when needed or to 535 completely recompute the hash. This mostly depends on the 536 previous note. 538 4.2.3. Limitations 540 With the current format proposed by ASTM only 7 messages can be 541 hashed reasonably in the above format. RESERVED padding, the 542 Signature Algorithm, Signature Length and redundant H-Alg, H-Len 543 fields could be removed. This would increase the total list of 544 hashes to 9 while losing word alignment of the hashes in each page. 546 To address this problem properly the authors feel that the 547 Authentication Messages needs to have a max bound of 10 pages, 548 instead of 5. 550 4.3. HIP Based Offline Authentication 552 0 1 2 3 553 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 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | | 556 | DEV HHIT | 557 | | 558 | | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | TIMESTAMP | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | | 563 | DEV HHIT | 564 | SIG | 565 . . 566 . . 567 . . 568 | | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | | 571 | DEV HI | 572 | | 573 | | 574 | | 575 | | 576 | | 577 | | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | AUTH TIMESTAMP | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | | 582 | AUTH HHIT | 583 | | 584 | | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | | 587 | AUTH | 588 | SIG | 589 . . 590 . . 591 . . 592 | | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 / PAYLOAD / 595 / / 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 DEV HHIT 16 byte Dev HHIT of EdDSA25519 HI 599 TIMESTAMP 4 byte packet trust until timestamp 600 DEV HHIT SIG 64 byte Signature of whole packet 601 DEV HI 32 byte Device HI of EdDSA25519 HI 602 AUTH TIMESTAMP 4 byte Dev HHIT trust until timestamp 603 AUTH HHIT 16 byte Authorizer's HHIT of EdDSA25519 HI 604 AUTH SIG 64 byte Signature of Device HHIT-HI 605 PAYLOAD 0 to n bytes of payload 606 Length 200 + n bytes 608 This specific format does not currently fit within the ASTM 609 specification. Requiring a minimum of 200 bytes, this would require 610 the Authentication Message to have 10 pages, instead of the current 5 611 page limit. 613 What this will grant, if attainable in future revisions of the ASTM 614 specification, is the ability to authenticate UA information when the 615 receiving device of the observer (e.g. a smartphone with a dedicated 616 RID application) has no Internet service (e.g. LTE signal). 618 By including the device HI along with a signature from the registry 619 the UA is under, we can assert trust of a given UA without requiring 620 the need for immediate reverse lookups online. 622 5. Example Use Cases 624 This section introduces potentional use cases of the HIP based 625 extensions to the proposed ASTM standard authentication message. 627 5.1. Trusted Messages 629 Using the HIP Based Authentication Wrapper any single Broadcast RID 630 message defined by ASTM can become what the authors refer to as a 631 "Trusted Message". 633 One specific use case that is useful in the UAS RID space is the 634 creation of a "Trusted Vector Message". By placing a previous [or 635 new] vector message into the Payload section of this format a 636 verifiable broadcast can be created. 638 Due to being signed this creates an authentic vector that is hard to 639 spoof, which can confirm flight paths in near real time. 641 The figure below is a example of a "Trusted Vector Message". Note 642 that the padding (RESERVED) byte are now gone. The "Trust Timestamp" 643 and "Vector Message" fields now span multiple pages instead of being 644 aligned to pages. 646 Page 0: 647 0 1 2 3 648 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 649 +---------------------------------------------------------------+ 650 | | 651 | ASTM UAS RID HEADERS +---------------+ 652 | | | 653 +-----------------------------------------------+ | 654 | | 655 | | 656 | | 657 | HHIT | 658 | | 659 | +---------------+ 660 | | / 661 +-----------------------------------------------+---------------+ 663 Page 1: 664 0 1 2 3 665 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 666 +---------------+-----------------------------------------------+ 667 | ASTM HEADER / Trust Timestamp | 668 +---------------+-----------------------------------------------+ 669 | | 670 | | 671 | | 672 | | 673 | HHIT Signature | 674 | | 675 | | 676 | | 677 | | 678 +---------------------------------------------------------------+ 680 Page 2: 681 0 1 2 3 682 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 683 +---------------+-----------------------------------------------+ 684 | ASTM HEADER | | 685 +---------------+ | 686 | | 687 | | 688 | | 689 | | 690 | HHIT Signature | 691 | | 692 | | 693 | | 694 | | 695 +---------------------------------------------------------------+ 697 Page 3: 698 0 1 2 3 699 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 700 +---------------+-----------------------------------------------+ 701 | ASTM HEADER | | 702 +---------------+ | 703 | | 704 | | 705 | | 706 | HHIT Signature | 707 | | 708 | | 709 | | 710 | +-------------------------------+ 711 | | Vector Message / 712 +-------------------------------+-------------------------------+ 714 Page 4: 715 0 1 2 3 716 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 717 +---------------+-----------------------------------------------+ 718 | ASTM HEADER / | 719 +---------------+ | 720 | | 721 | | 722 | | 723 | | 724 | Vector Message | 725 | | 726 | | 727 | | 728 | | 729 +---------------------------------------------------------------+ 731 5.2. Wrapped Signed Hashes 733 Using the HIP Based Authentication Wrapper a [short] list of hashes 734 can be signed. These hashes are of previous individual RID messages. 736 This follows the format of the Signed Hash List, excluding the 737 psuedo-blockchain hashes and various other fields enabling it to fit 738 within the 23 byte limit of the final page. 740 To the authors, this format has limited use due to numerous concerns 741 of replay attacks. It is suggested to instead use the full Signed 742 Hash List format. 744 Page 0: 745 0 1 2 3 746 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 747 +---------------------------------------------------------------+ 748 | | 749 | ASTM UAS RID HEADERS +---------------+ 750 | | RESERVED | 751 +-----------------------------------------------+---------------+ 752 | | 753 | | 754 | | 755 | HHIT | 756 | | 757 | | 758 | | 759 +---------------------------------------------------------------+ 761 Page 1: 762 0 1 2 3 763 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 764 +---------------+-----------------------------------------------+ 765 | ASTM HEADER | Trust Timestamp / 766 +---------------+---------------+-------------------------------+ 767 / | RESERVED | | 768 +---------------+---------------+ | 769 | | 770 | | 771 | | 772 | HHIT Signature | 773 | | 774 | | 775 | | 776 +---------------------------------------------------------------+ 778 Page 2: 779 0 1 2 3 780 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 781 +---------------+-----------------------------------------------+ 782 | ASTM HEADER | | 783 +---------------+ | 784 | | 785 | | 786 | | 787 | | 788 | HHIT Signature | 789 | | 790 | | 791 | | 792 | | 793 +---------------------------------------------------------------+ 795 Page 3: 796 0 1 2 3 797 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 798 +---------------+-----------------------------------------------+ 799 | ASTM HEADER | | 800 +---------------+ | 801 | | 802 | | 803 | | 804 | | 805 | HHIT Signature | 806 | | 807 | | 808 | | 809 | | 810 +---------------------------------------------------------------+ 812 Page 4: 813 0 1 2 3 814 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 815 +---------------+---------------+-------------------------------+ 816 | ASTM HEADER | H-Alg | H-Len | RESERVED | 817 +---------------+---------------+-------------------------------+ 818 | Message Hash | 819 +---------------------------------------------------------------+ 820 | Message Hash | 821 +---------------------------------------------------------------+ 822 | Message Hash | 823 +---------------------------------------------------------------+ 824 | Message Hash | 825 +---------------------------------------------------------------+ 826 | Message Hash | 827 +---------------------------------------------------------------+ 829 6. IANA Considerations 831 TBD 833 7. Security Considerations 835 TBD 837 8. Acknowledgments 839 TBD 841 9. References 843 9.1. Normative References 845 [NIST.SP.800-185] 846 Kelsey, J., Change, S., and R. Perlner, "SHA-3 derived 847 functions: cSHAKE, KMAC, TupleHash and ParallelHash", 848 DOI 10.6028/nist.sp.800-185, National Institute of 849 Standards and Technology report, December 2016, 850 . 852 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 853 Requirement Levels", BCP 14, RFC 2119, 854 DOI 10.17487/RFC2119, March 1997, 855 . 857 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 858 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 859 May 2017, . 861 9.2. Informative References 863 [I-D.moskowitz-hip-hhit-registries] 864 Moskowitz, R., Card, S., and A. Wiethuechter, 865 "Hierarchical HIT Registries", draft-moskowitz-hip-hhit- 866 registries-01 (work in progress), 17 October 2019, 867 . 870 [I-D.moskowitz-hip-hierarchical-hit] 871 Moskowitz, R., Card, S., and A. Wiethuechter, 872 "Hierarchical HITs for HIPv2", draft-moskowitz-hip- 873 hierarchical-hit-02 (work in progress), 17 October 2019, 874 . 877 [I-D.moskowitz-hip-new-crypto] 878 Moskowitz, R., Card, S., and A. Wiethuechter, "New 879 Cryptographic Algorithms for HIP", draft-moskowitz-hip- 880 new-crypto-02 (work in progress), 3 October 2019, 881 . 884 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 885 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 886 RFC 7401, DOI 10.17487/RFC7401, April 2015, 887 . 889 Authors' Addresses 891 Adam Wiethuechter 892 AX Enterprize 893 4947 Commercial Drive 894 Yorkville, NY 13495 895 United States of America 897 Email: adam.wiethuechter@axenterprize.com 898 Stuart W. Card 899 AX Enterprize 900 4947 Commercial Drive 901 Yorkville, NY 13495 902 United States of America 904 Email: stu.card@axenterprize.com 906 Robert Moskowitz 907 HTT Consulting 908 0000 909 Oak Park, MI 48237 910 United States of America 912 Email: rgm@labs.htt-consult.com